总结这套数据库迁移经验，真是一路跌跌撞撞才摸索出来的东西，分享给你们参考参考

（来源：某技术团队内部复盘文档）

哎，说起这次数据库迁移，真是一把辛酸泪，本来以为就是个把数据从A搬到B的活儿，结果差点搞出个大事故，现在总算风平浪静了，我们把这一路上踩过的坑、总结的经验老老实实记下来，你们以后要是遇到类似的事儿,可千万别再掉进同一个坑里了。

第一，千万别小看准备工作，它比迁移本身还重要。

我们一开始就犯了轻敌的错误，想着新数据库性能参数都调好了，迁移工具也选了个流行的，就直接开干，结果第一步就卡住了——数据校验没过关，老数据库里有些数据，按照表结构来说是不合法的，比如该是数字的地方存了个空字符串，或者日期格式千奇百怪，这些数据在老系统里因为历史原因一直跑得好好的，但新数据库比较严格,直接拒绝接收。

教训： 迁移前，必须花大力气做一次全面的数据“体检”。（来源：数据不一致导致的迁移失败）得写脚本把老数据库里的数据彻底摸排一遍，看看有没有脏数据、重复数据、或者不符合新数据库约束的数据，这个清理和转换的工作，一定要在正式迁移之前做完，不然就会像我们一样，在迁移过程中不断报错,手忙脚乱。

第二，迁移工具不是万能的，一定要自己亲手测试。

我们选了一个号称“一键迁移”的工具，宣传得天花乱坠，我们也就偷了个懒，没有充分测试，结果到了真正切流量的时候，发现有一种特殊类型的大字段数据，迁移过去后内容竟然丢了！幸好我们在预发布环境做最后验证时发现了,不然直接就是线上事故。

教训： 再好的工具也不能完全信任。（来源：迁移工具的数据丢失隐患）必须用真实的、有代表性的数据样本，完整地跑一遍迁移流程，不仅要看迁移成功与否，还要逐表抽样对比，确保数据一条没少，一个字节都没错，这个测试过程可能很枯燥,但能救命。

第三，要有能“一键撤回”的后路。

迁移那天晚上，我们按计划把应用的写操作停了，开始切流量，结果刚切了10%的流量到新数据库，监控警报就响了，新数据库的CPU直接飙到100%，响应速度慢得吓人，我们当时就慌了，是新数据库配置不对？还是我们的SQL语句在新环境下性能太差？

教训： 幸好我们提前设计了一个非常关键的东西：快速回滚方案。（来源：切流失败时的紧急回滚）我们事先把老数据库完全锁住，但保持运行状态，应用层也做了配置，可以在几分钟内把流量全部切回老数据库，当时我们一看情况不对，立刻执行回滚，先保证线上服务恢复正常，这个“后悔药”太重要了，没有它,我们那天晚上就只能眼睁睁看着服务崩溃。

第四，迁移不是终点，迁移后的“磨合期”更关键。

虽然我们后来解决了性能问题（发现是某个索引没建好），成功完成了迁移，但以为这就万事大吉了，结果接下来的一周，小问题不断，有些报表跑出来数字不对，后来发现是某个复杂的查询语句，在老数据库和new数据库里执行的结果有细微差别，还有些后台任务，因为连接方式变了,偶尔会超时。

教训： 数据库迁移后，必须有一个详细的观察期。（来源：迁移后遗留问题排查）要盯紧各项监控指标：慢查询、错误日志、业务数据准确性对比，最好能安排专人在接下来的一两周内，啥也别干，就专门处理和新数据库相关的问题，提前准备好各种排查工具和脚本,问题来了才能快速定位。

第五，人是最大的变量，沟通不到位全是坑。

这次迁移涉及好几个团队：我们后端、运维、还有业务方，一开始我们关起门来搞，快上线了才通知业务方要停服几小时，结果被业务方怼回来了，说那个时间段有重要活动，后来我们学乖了，提前几周就拉通各方，一起确认迁移时间、影响范围、应急预案,把每个人都安排得明明白白。

教训： 技术再牛，沟通不到位也白搭。（来源：跨团队协作的沟通教训）一定要把迁移的影响、风险、计划提前、清晰地告知所有相关方，特别是非技术部门，取得他们的理解和支持，万一真出了点问题，大家也能一起想办法,而不是互相甩锅。

这次经历让我们彻底明白，数据库迁移绝对不是一个单纯的技术活，它更像一个系统工程，考验的是团队的细心、耐心、沟通和应急预案能力，技术选型反而成了最简单的一环，希望我们这些用“跌跌撞撞”换来的经验，能给你们提个醒,让你们的路走得顺一点。