上个月，一个朋友的公司搞数据库迁移，从MySQL迁到PostgreSQL，本以为是换个地方搬个家，结果光数据校验就折腾了三天，发现少了一百多万条记录，还是用信用卡对账单才发现的。这种事我见得太多了。数据库迁移听着挺高大上，其实就是一场信息搬家，但很多人低估了它的风险。别指望靠运气搞定这种活，你需要的是一份能复用的迁移方案模板，把坑提前填上，而不是掉进去再爬。
先说说迁移前的摸底工作。很多人一上来就想着怎么把数据导出来，结果发现表结构不兼容，字段类型对不上，索引全废了。这就好比你要搬进新家，结果门框比旧家具还窄。所以第一步，你得先做个完整的数据库清单，把源库和目标库的表结构、字段类型、索引、约束、存储过程全列出来，逐项对照。别信什么自动对比工具，手动过一遍比什么都靠谱。我见过一个项目，源库用的是UTF-8编码，目标库默认是Latin1，迁移完所有中文全变乱码，花了两个星期重新清洗数据。这种坑，提前花半天就能避开。
数据迁移方案的核心，不是怎么把数据倒过去，而是怎么保证倒过去的数据是对的。很多人用或者一跑了之，结果遇到大表就直接超时断连。正确做法是先做分片迁移，按主键或者时间戳把大表切成小块，每块一个事务，失败了好回滚。同时，你得给迁移过程做监控，记录每个片的迁移时间、数据量、错误日志。我习惯用一张控制表，记录迁移的批次号、开始时间、结束时间、状态和错误信息。这样万一中间断了，你翻一下表就知道从哪接着干，不用从头再来。
增量迁移这块最容易出问题。全量迁移把历史数据倒过去只是第一步，真正痛苦的是业务不能停，源库还在不断写入新数据。这时候你需要一个增量同步方案。常见的做法是开启源库的binlog或者WAL日志，用工具比如Debezium、Canal或者自己写个监听器，把增量变更实时同步到目标库。但这里有个坑：如果源库和目标库的字段映射关系不对，增量数据就全乱套了。我见过一个团队，把时间戳字段从UTC转成东八区时没做处理，结果客户凌晨的订单全部显示成前一天。所以增量同步阶段，一定要做字段级别的映射校验，每一条变更都要验证。
数据校验是很多人最想省掉的环节。你想想，迁移完发现数据对不上，业务人员找你，你就得从头排查，比直接做校验还累。校验不是简单对比数量，你得对比每条记录的关键字段。我习惯用哈希校验的方式：把源库和目标库的同一张表按主键排序，逐行计算MD5值，然后对比差异。大表就按分片逐片对比。别嫌麻烦，我见过一个案子，迁移完用户余额对不上，发现是字段类型不同，源库是decimal(10,2)，目标库是float，精度丢失导致每笔都少了几分钱，累积下来亏了好几万。
灰度验证是一道防线。别一迁移完就让业务全量切过来，你得先让一小部分用户跑在新库上，跑几天看看效果。我通常会挑一个非核心业务模块，比如用户个人中心或者后台报表系统，先切到新库。观察响应时间、错误率、数据一致性。如果没有异常，再逐步扩大范围。这个过程要准备回滚方案，万一新库出问题，能在15分钟内切回老库。回滚不是简单改个连接串，你得提前备份老库的增量数据，确保切回来时数据不丢。
说一句，迁移方案模板不是一成不变的。不同数据库、不同业务场景，细节都不一样。但核心逻辑是一样的：先摸底、再分片、加监控、做校验、灰度切。你把这个框架搭好，每次迁移就是在现有模板上微调，而不是从零开始。下次有同事问你要不要做个迁移，你就把这套模板甩给他，告诉他：照着做，别自己瞎琢磨。迁移这种活，不怕慢，就怕错。准备好了再动手，永远比事后救火划算。
