上周五晚上十点，我盯着屏幕上的进度条，手心全是汗。公司要把核心业务数据库从阿里云迁到腾讯云，整整 2 TB 的数据，迁移窗口只有 6 小时。这不是我第一次干这种事，但每次心跳都会加速。数据库迁移表面上是技术活，实际上更像在拆弹。你永远不知道下一秒会出现什么幺蛾子——字符集不兼容、存储过程报错、主键冲突，随便一个就能让你从深夜加班到天亮。更刺激的是，业务部门的人还在微信群里问：“明天早上系统能正常用吗？”我只能回一个“没问题”的表情包，心里却在祈祷别出岔子。
干这行的人都知道，数据库迁移最怕的不是技术难度，而是人坑人。我有个朋友在某大厂，去年做迁移时，业务方信誓旦旦地说“数据量不大，就 300 GB”。结果真迁移时发现，光日志表就有 3 TB，业务方根本没告诉你他们有个自动清理程序关了半年。更离谱的是，有同事遇到的情况：业务方说“这表没用了，可以删”，结果删完后发现那是财务系统的核心表，整个财务部门三天没法结账。这种事多了，我养成了一个习惯：所有数据量、表结构、依赖关系必须自己亲自确认一遍，业务方的话只能信一半。
说到技术选型，又是一个坑。市面上主流的迁移工具不少，但每个都有自己的脾气。DataX 适合批量迁移，但对实时同步支持不好；Canal 擅长解析 MySQL 的 binlog，但遇到复杂 DDL 操作就容易崩溃；DTS 是云厂商的官方工具，用起来方便，但跨厂商迁移时经常遇到兼容性问题。我去年做过一次从 MySQL 到 PostgreSQL 的迁移，用了 Kettle 做 ETL，结果发现 PostgreSQL 对某些 MySQL 特有的函数根本不支持，比如 GROUP_CONCAT，只能写脚本一个个替换，光改 SQL 语句就花了两天。所以现在我的原则是：能用原生工具就别用第三方，能增量同步就别全量迁移，能分批就别一次性全上。
数据校验是很多人会忽略的环节。我见过最离谱的案例是：某公司把数据库从 SQL Server 迁到 MySQL，迁移完成后业务正常运行，直到一个月后做财务对账时才发现差了 20 万条记录。原因是 SQL Server 的 datetime 类型和 MySQL 的 datetime 精度不一样，导致时间戳在毫秒级出现偏差。还有一次，某同事在做字符集迁移时，没注意到源库是 utf8mb4，目标库是 utf8，结果所有 emoji 表情全变成了问号。自那以后，我每次迁移都会做三遍校验：第一遍用 MD5 比对记录数，第二遍随机抽样对比字段值，第三遍写脚本全量比对关键字段。虽然麻烦，但总比事后补救强。
业务割接最考验的是沟通能力。技术方案再好，如果业务方不配合，一切等于零。我有个血的教训：去年做一次迁移，技术方案都写好了，上线时间也定了，结果业务方临时说要加一个新功能，导致数据模型需要调整。我当时没坚持原则，答应延期一周。结果这一周里，业务方又提了三个新需求，迁移方案改了四版，上线时间晚了整整一个月。现在我的做法是：迁移方案一旦确定，就进入“冻结期”，任何新增需求都必须写在“后续优化”清单里，绝不妥协。这不是技术傲慢，而是风险管理。
迁移完成后的性能调优是另一个容易踩坑的地方。很多人在迁移后只检查数据是否完整，却忽略了性能问题。我有次把数据库从商业版 Oracle 迁到开源版 MySQL，数据完全一致，但业务方反馈查询速度慢了三倍。排查后发现，Oracle 的优化器会自动处理索引使用，而 MySQL 需要手动调优。更头疼的是，有些 SQL 在 Oracle 里跑得好好的，迁到 MySQL 后因为语法差异导致执行计划完全不同。花了两周时间重新分析慢查询，优化了十几个索引和 SQL，性能才恢复正常。这件事让我明白：迁移不是终点，调优才是开始。
说点实在的。数据库迁移本质上是在跟不确定性博弈。你永远无法预知所有风险，但可以通过规范流程降低概率。我们团队有个不成文的规定：每次迁移前必须做一次完整的模拟演练，包括网络中断、主键冲突、数据不一致等场景。演练中发现的任何问题，都必须列入风险清单，逐一解决后才能正式迁移。虽然流程繁琐，但效果明显：今年上半年我们做了 6 次迁移，全部成功上线，没有一次需要回滚。这不是运气，而是用时间和耐心换来的确定性。如果你也在考虑数据库迁移，我的建议是：慢一点，再慢一点，宁可被业务方催着走，也别被事故逼着跑。
