干了这么多年数据工作，我越来越觉得数据库迁移这事儿，技术难点从来不在“怎么迁”，而在“迁完怎么证明没问题”。你想想，代码重构有单元测试、接口测试层层把关，唯独数据库迁移，很多人把数据一导，看两眼行数对得上就敢上线。结果呢？半夜三点被电话叫醒，说线上查询慢得像蜗牛，或者某个字段的值莫名其妙变了。所以这份指南，我就把自己踩过的坑、总结出来的套路，掰开揉碎了跟你聊聊。
先说说迁移前最容易被忽略的一件事：搞清楚你到底在迁什么。别笑，我真见过有人把生产库的表结构和测试库的混在一起比对。你得先把源库的所有对象列个清单，表、视图、存储过程、触发器、序列、外键约束，一个都不能少。光是表还不够，每张表的索引、分区、默认值、自增起始值，这些细节才是迁移后出问题的重灾区。我习惯的做法是写个脚本，把源库的元数据全量导出成文本，再和迁移后的目标库逐项比对。这个步骤虽然枯燥，但能帮你省掉后面百分之八十的排查时间。
接着就是数据一致性校验，这活儿比想象中麻烦。很多人以为SELECT COUNT(*)两边一样就万事大吉，可数据量一大，统计信息不准确，COUNT都可能骗你。更靠谱的办法是按主键分段抽样，再对关键业务字段做MD5或哈希比对。我有个老同事，他做校验时会把每张表的行数、关键字段的SUM值、MAX和MIN都算一遍，做成一张对比报告。虽然土，但真能发现问题——有一次就是SUM值对不上，查了半天才发现是某个字段的精度在迁移过程中被悄悄改了，从DECIMAL(10,2)变成了DECIMAL(8,2)。
再说说约束和索引，这块是迁移后性能问题的头号嫌疑犯。数据导过去之后，外键约束可能因为数据顺序问题没建上，索引可能因为批量导入被禁用后忘了重建。你要做的不是等迁移完再检查，而是在迁移脚本里就明确顺序：先禁约束导数据，再开约束做校验，统一建索引。而且索引建完一定要跑一遍EXPLAIN PLAN，看看关键查询的执行计划跟源库是否一致。有时候目标库的优化器版本不同，同样的SQL走的索引路径完全不一样，这种坑防不胜防。
业务功能验证这块，我强烈建议你别用测试账号走一遍流程就算完。你得准备一套跟生产环境几乎一样的数据样本，把核心业务链路从头到尾跑一遍。比如电商系统，从下单、支付、发货到售后，每一步涉及的表都要查一遍数据是否正确。更狠一点的做法是，把迁移前的生产流量在测试环境回放一遍。我有次帮客户做迁移，就是用他们上周的线上日志重新跑了一遍，结果真发现有个报表查询在目标库上报错，原因是某个Oracle特有的函数在PostgreSQL里根本不存在。
别忘了性能对比测试。很多迁移项目数据对了、功能通了，一上线就卡死，就是因为忽略了这一步。你要挑出平时最慢、最频繁的几十条查询，分别在源库和目标库上跑，对比执行时间和资源消耗。注意控制变量：同样的数据量、同样的并发、同样的硬件配置（或者至少是同等规格）。我见过最离谱的情况是，有人在性能测试时源库用了生产环境的高配机器，目标库却用了个低配虚拟机，结果差距一大半，白白浪费了几天排查时间。
回滚方案这事儿，说多了都是泪。很多人觉得迁移都成功了还准备什么回滚，结果上线后第二天发现有个老报表的数据源接错了，想回退却发现备份文件被覆盖了。我的建议是，迁移前把源库做一次完整备份，迁移完成后不要急着删，至少要保留一个完整的发布版本。同时写清楚回滚触发条件和操作步骤，让团队里任何一个人照着文档都能操作。别把回滚方案存在某个人的电脑里，要放进知识库，版本化管理。
说个很多人忽视的点：迁移后的监控和观察期。数据迁完、测试通过、上线切换，这只是开始。你要在接下来至少一周内，盯着慢查询日志、数据库连接数、锁等待时间这些指标，跟迁移前的基线做对比。我见过一个案例，迁移后所有功能都正常，但跑批任务每天凌晨都会超时，查了三天才发现是目标库的参数max_connections设置得比源库小，导致并发一高就排队。这种问题，光靠功能测试根本测不出来，必须靠观察期数据说话。
绕了这么一大圈，其实数据库迁移测试的核心就三件事：数据对不对、功能跑不跑得通、性能扛不扛得住。但每件事要做到位，都需要提前规划、逐项验证、留好退路。工具和脚本能帮你省力，但替代不了人的判断。你需要在每一步都问自己：如果这一步出错了，我能不能及时发现？能不能快速恢复？把这两个问题想清楚了，迁移这事儿就算成功了一大半。
