数据库搬家：跨版本升级的稳妥路径

跨大版本升级数据库，最忌讳在老库上原地直接升：升失败没有退路，升成功也回不去。稳妥的路线永远是新起一套环境，验证通过再切流量。 升级前的兼容性检查 MySQL 用 mysqlcheck -A --check 把所有表过一遍；再逐条核对目标版本的更新文档，把 my.cnf 里已废弃的参数清掉，带病参数会让新版本直接拒绝启动。PostgreSQL 官方工具 pg_upgrade 加 --check 参数，能在不动原库的前提下预演整个升级，把问题提前暴露。检查阶段发现的问题，比升级当场的报错好处理得多。时间安排上，检查和演练至少留一周：第一次在新环境导入后完整跑一遍业务回归，把问题都暴露在正式切换之前。 路径一：导出导入 适合中小型库： mysqldump -uroot -p --single-transaction --routines --triggers --databases appdb > appdb.sql 导入新版本实例：mysql -h 新库地址 -uroot -p < appdb.sql。逻辑导出的好处是顺便清理了碎片和潜在坏页，坏处是耗时长，几百 G 的库不适合这条路。 路径二：复制升级 适合大库和停机敏感的业务：把目标版本的新实例配置成老库的从库，等数据追平，选低峰切换——停写、确认复制延迟归零、应用连接串指向新库。PostgreSQL 用流复制同理。切换窗口能压到分钟级。 回退点怎么留 切换前对老库做最后一次全量备份；老实例不要删，停服保留一到两周，新库出问题能快速切回；应用侧把新旧两套连接串都留在配置里，切换和回退都只是改配置重启的事。切换当天把每一步的时间点记下来：几点停写、几点切流、几点验证完成，万一要回退，这份记录就是现成的操作手册。 验证清单 切完逐项过：关键表行数对得上、核心业务流程完整走一遍、主从延迟归零、慢查询日志没有异常增长。全过了，这次搬家才算落地。