咱们直接聊数据库迁移这事儿。很多人一听“迁移”两个字就头大，觉得是技术活儿里的“硬骨头”。但其实，只要拆开来看，它没那么玄乎。我见过不少团队，一上来就急着动手，结果数据丢了、业务停了，还得花几倍时间擦屁股。今天就用一个真实的实例，从头到尾捋一遍，从规划到落地，咱们看看每一步到底该怎么走。
先说说背景。前阵子有个朋友的公司，他们原来的数据库跑在MySQL 5.6上，用了五六年，数据量涨到快2TB。业务一多，查询慢得像蜗牛，高峰期CPU直接飙到95%。老板拍板说，必须升级到MySQL 8.0，还得从自建机房搬到云上。这事儿看着简单，但里头坑不少。他们找到我帮忙参谋，我拉了个小团队，前后花了三周时间，才把迁移这事儿干利索。今天就把这些经验掰开揉碎了讲。
规划阶段最容易被忽视，但也是最关键的。很多人觉得，规划不就是列个清单吗？其实远不止。你得先搞清楚两个问题：迁移的目标是什么？迁移的范围有多大？这个朋友的公司，目标是提升查询性能，同时降低运维成本。所以，他们选择MySQL 8.0是因为它支持窗口函数和哈希索引，能优化慢查询。迁移范围则包括全部业务表、存储过程、定时任务，还有历史归档数据。我让他们画了一张数据流向图，把每个应用的依赖关系标出来，这才发现有个老接口还连着一个废弃的数据库，差点把迁移范围搞错。所以，规划阶段得花至少一周时间，把数据量、表结构、索引、权限、字符集这些细节全摸清。
接下来是方案设计。迁移方案不是拍脑门想出来的，得根据数据量和业务容忍度来定。这个公司业务允许最长两小时的停机窗口，但数据量有2TB，全量迁移加增量同步，两小时根本不够。我们选了“双写”方案：先在云上搭一套新库，把旧库数据全量导入，然后让应用同时往新旧库写数据，等新库追上旧库的进度，再切换流量。这个方案的好处是，切换瞬间完成，业务几乎无感。但代价是，应用代码得改，得支持同时写两个库。我们花了两天改代码，又花一天测试，确保双写逻辑没bug。如果你业务不允许停，或者数据量特别大，像10TB以上，那可能得考虑用CDC工具（比如Debezium）做实时同步，但复杂度会指数级上升。
数据迁移执行阶段，得特别小心。很多人以为，用mysqldump导个文件，再往新库一导入就完事了。但2TB的数据，mysqldump导出来文件得有几百GB，传输和导入时间都太长。我们用了MySQL官方推荐的MySQL Shell工具，它支持并行导出导入，能把速度提升3到5倍。具体操作是：先在旧库上跑一遍，把数据拆成多个小文件，然后在云上新库上跑并行导入。整个过程花了大概8小时，比传统方式快了一倍。但中间出了个小插曲——有个表的字符集是latin1，新库默认是utf8mb4，导入时报了字符集不兼容的错误。我们赶紧暂停导入，在目标库上先改了对应表的字符集设置，才继续跑。所以，执行前一定要跑一遍预检查脚本，把字符集、主键、外键、触发器这些潜在冲突全查出来。
数据迁移完，只是走了一半路。验证环节才是真正的“生死局”。很多人迁移完，一看数据量对上了，就以为万事大吉。但数据量对不代表数据内容对。我们当时做了三层验证：第一层，全量对比行数，用对每个表做对比；第二层，抽样对比字段内容，用工具比如pt-table-checksum检查数据一致性；第三层，跑业务测试用例，让QA团队把核心业务流程走一遍，比如下单、支付、退款，看新库能不能正常跑通。结果，在抽样对比时发现，有个自增ID的表，旧库最大值是100万，新库却从1开始重新计数了。这是因为导入时忘记重置自增值，导致新插入的数据ID冲突。我们手动改了自增值后，才恢复正常。所以，验证环节宁可多花时间，也不能偷懒。
切换上线那一步，最考验心态。我们选在凌晨两点，业务低峰期操作。先发公告通知用户系统维护，然后停掉旧库的写入，等双写队列清空，再把应用流量全切到新库。整个过程花了15分钟，业务恢复后，查询响应时间从原来的3秒降到了0.2秒，效果立竿见影。但切换完不是终点，还有回滚预案。我们保留了旧库的只读权限，一旦新库出问题，可以立刻切回去。另外，监控也得跟上，重点看慢查询日志、连接数和CPU使用率，确保新库稳定运行至少一周。这个公司后来发现，有几个报表查询在新库上反而变慢了，原因是MySQL 8.0的优化器对某些SQL执行计划变了。我们调整了索引和查询语句，才把性能拉回来。所以，切换后的一周，是真正的“观察期”，别放松警惕。
聊聊经验教训。这次迁移下来，有三点特别重要：第一，永远别低估数据依赖的复杂性。像字符集、自增值、存储过程这些细节，一个没注意，就可能翻车。第二，自动化工具能省力，但不能完全信。我们用了MySQL Shell，但预检查还是得手动补一补，比如检查外键约束是否完整。第三，沟通比技术更重要。迁移前，得让业务团队、运维团队、开发团队都清楚时间窗口和风险。比如，我们提前一周跟业务方确认了凌晨切换，但有个老业务系统半夜有定时任务，差点冲突。后来协调改了定时任务的时间，才避免问题。总的来说，数据库迁移像一场手术，规划是术前检查，执行是手术过程，验证是术后恢复，每一步都得仔细。只要把每个环节拆细、做透，迁移其实没那么可怕。
