这事儿得从一次深夜加班说起。凌晨两点，我盯着屏幕上跳动的进度条，咖啡杯底已经留下了圈圈褐色的印子。数据库迁移跑了六个小时，离预计完成时间还差一半。隔壁工位的运维兄弟趴在桌上睡着了，键盘上还压着一张写满参数的便签纸。这种场景，干过系统迁移的人都懂——数据库迁移看着是技术活，实际上是心累活。
我见过太多团队栽在同一个坑里：数据一致性。你以为是简单的数据拷贝，但源库和目标库之间，那些看不见的约束、触发器、存储过程，哪个没处理好，迁移完一查，数据对不上，业务直接崩。一个朋友的公司把 Oracle 迁到 MySQL，跑了大半个月的迁移脚本，结果发现自增主键的初始值没对齐，订单号全乱套。你说这事闹心不闹心？所以迁移前务必要做全量的数据校验，不光要比对行数，还得抽样关键字段，最好用工具生成数据比对报告。
另一个高频问题是性能下降。迁移完新数据库，业务一跑，查询慢了十倍。老板拍桌子问怎么回事，你翻半天文档才发现，原来是索引没重建。源库的索引结构到新环境不一定适用。就好比把老房子的门拆了，装到新房子上，尺寸不对，门都关不上。更麻烦的是，有些数据库引擎的查询优化器逻辑不同，同样的 SQL 在 MySQL 里走索引，到了 PostgreSQL 就全表扫描。所以迁移后一定要做一轮压测，打开慢查询日志，一条条排查。
权限和认证，这个坑也特别深。老系统里可能存了几百个用户，各种角色、各种权限粒度。迁移到新库，你以为用同样的 SQL 就能搞定，结果发现新数据库的权限模型完全不一样。比如从 MySQL 迁到 MongoDB，用户认证机制变了，连接字符串都得重写。记得有一次，我亲眼看到一个团队迁移完后，应用连不上库，查了三天才发现是 SSL 证书没配。就这一个小细节，拖了项目三天工期。所以迁移前一定要把权限矩阵梳理清楚，最好写脚本自动化配置。
还有个事儿，很多人忽略——时间同步。迁移过程中，如果源库和目标库的系统时间不一致，日志归档、增量同步都会出问题。尤其是实时同步的场景，时间差哪怕一秒，binlog 的位置就对不上了。我认识一个 DBA，迁移时没检查时间同步，结果数据同步工具报了上千个冲突，他手动修了整整一个周末。你说冤不冤？所以迁移前先确保所有服务器的 NTP 服务正常，时间偏差控制在毫秒级。
业务中断时间更是绕不开的痛点。很多公司要求零停机迁移，但现实是，数据量上 TB，网络带宽有限，全量加增量同步，少说也得几个小时。这期间业务怎么写数据？常见做法是双写，但双写又会引出一致性问题。有团队设计了个方案：先切读流量，再切写流量，中间用消息队列缓冲。听起来完美，可一旦消息队列崩了，数据就丢了。所以别迷信方案，必须根据业务容忍度来设计。比如电商大促前，宁可多花一周做灰度迁移，也别冒风险搞一刀切。
回滚策略必须重点说明。很多团队迁移前信心满满，觉得脚本写好了、测试跑过了，不会出问题。结果真上线后，数据一丢，业务停摆，才发现没有准备回滚方案。更糟的是，回滚时才发现源库已经被清理。我见过最夸张的一次，某公司把 MySQL 迁到 TiDB，迁移完发现业务不兼容，想回滚，结果源库的数据被删了，只能从备份恢复，丢了 12 小时的数据。所以迁移前务必要保留源库快照，回滚脚本也要提前写好并测试。
版本兼容性也常被轻视。数据库厂商升级大版本时，很多语法会废弃。比如 MySQL 5.7 到 8.0，GROUP BY 的行为变了。如果你用了老版本的隐式排序，迁移后排序结果全乱。还有 Oracle 到 PostgreSQL，PL/SQL 的存储过程需要重写。这些细节光靠自动化工具搞不定，必须人工逐条审查。迁移前一定要跑语法兼容性检查，最好用工具把所有 SQL 扫一遍。
说个实在的——人。数据库迁移，技术只占一半，另一半是沟通和项目管理。你得跟业务方确认停机窗口，跟开发团队对齐数据模型，跟运维团队协调资源。哪个环节没对齐，都可能出幺蛾子。我有个朋友，迁移前忘了通知测试组，结果测试环境和生产环境数据不一致，测试出来的结果全是错的，浪费了一周时间。所以迁移项目最好设专人统筹，每个节点都要有确认签字。
说了这么多，核心只有一句话：别把数据库迁移当成一次性的技术操作，它是个系统工程。从评估到测试，从执行到验证，每一步都得有人盯着。那些踩过的坑，都是用真金白银买来的教训。下次带队做迁移时，不妨把上面这些问题列成清单，逐项打勾确认。别嫌麻烦，省下的时间，足够你补几个安稳觉了。
