去年帮朋友公司做了一次 MySQL 8 数据库迁移，感觉就像给一辆开了十年的老车换发动机。他们原先用的是 MySQL 5.7，跑了五六年，数据量堆到快 2 TB，日常查询开始卡顿，凌晨跑报表恨不得让人等到上班。老板拍桌子说必须升级，但真动手才发现，这不是装个新版软件那么简单。
先说迁移前最让人头疼的——兼容性检查。MySQL 8 与 5.7 比，改了不少默认行为，比如字符集从 latin1 变成了 utf8mb4，排序规则也更严格。我们那套系统里，有个老模块专门用 GBK 编码存用户昵称，跑在 5.7 上一直好好的。一升级到 8，查询直接报错，因为 8 默认的 utf8mb4 不认 GBK。后来翻文档才发现，8 对字符集的处理更“较真”，不兼容的编码会直接罢工。所以迁移前，我让团队把所有表结构、存储过程、触发器的 SQL 脚本都跑了一遍 MySQL 8 的兼容性检查工具，光是修那些隐式类型转换的问题就花了三天。
迁移工具的选择也挺有意思。官方推荐 MySQL Shell 的升级检查器和数据迁移功能，但实际操作下来，对于超过 500 GB 的库，用 mysqldump 导数据简直是噩梦。我们试过一次，半夜开始导，到第二天下午还没结束，中间网络波动还断了两次。后来改用 Percona XtraBackup 做物理备份，再在目标服务器上恢复，速度直接快了十倍。不过物理迁移有个坑——需要确保源库和目标库的 MySQL 小版本号一致，否则恢复后会报系统表不匹配。我们那次就因为目标库装的是 8.0.32，源库是 8.0.28，恢复后启动失败，折腾了一小时才发现是 glibc 版本不同导致的。
数据一致性验证是迁移里最磨人的环节。你以为数据复制过去就完事？天真。有一次迁移完业务库，跑了个简单的 COUNT(*) 对比，两边数据量一样，大家正准备庆祝。结果运维同事多留了个心眼，随机抽了 1000 条记录做字段级比对，发现有个 timestamp 字段在源库是 ‘2023‑06‑30 23:59:59’，到了目标库变成了 ‘2023‑07‑01 00:00:00’。查了半天，原来是 MySQL 8 对 timestamp 的默认精度处理变了，5.7 里存的是秒级，8 里自动转成毫秒级，导致四舍五入。这种细节不测出来，上线后财务对账会崩溃。
性能调优这块，MySQL 8 的优化器确实比 5.7 聪明，但也不是无脑快。我们有个核心查询，5.7 里跑 0.3 秒，迁移到 8 后直接飙到 3 秒。用 EXPLAIN 一看，优化器选错了索引，它觉得全表扫描加排序比用索引更快。后来强制指定索引，又调整了 optimizerswitch 参数，才恢复到 0.2 秒。更诡异的是，8 引入了 hash join，对某些多表关联查询，它默认走 hash join 反而比原来的 nested loop 慢。这些坑不实际跑一遍生产级查询，根本发现不了。
回滚方案是一道防线，但很多人会忽略。我们当时设计的是“双写”策略——迁移期间，应用层同时写源库和目标库，但读请求只走目标库。这样如果目标库有问题，一秒就能切回源库。不过双写也有代价，代码里要加事务处理的逻辑，还要处理两个库之间的数据冲突。我们踩过的一个坑是：双写时源库和目标库的自增主键 ID 不一致，导致关联查询乱掉。后来在应用层统一用 UUID 做主键，才解决了这个问题。这套方案虽然复杂，但真正上线那天，我们切流量过去后监控发现目标库 CPU 飙到 90%，5 秒内就切回了源库，业务零感知。
迁移完成后，别忘了收拾烂摊子。MySQL 8 的密码加密方式从 mysqlnativepassword 改成了 cachingsha2password，老版本的客户端连不上。我们有个内部监控系统用的 PHP 5.6，连数据库直接报认证失败，被迫升级了 PHP 版本。另外，8 里废弃了部分系统变量，比如 querycachesize，如果老配置里还留着这些参数，MySQL 会直接启动失败。我们那次上线后，有同事在配置文件里忘了删掉 querycache_type，导致第二天重启数据库时挂掉，排查了半小时才发现。
总结下来，MySQL 8 迁移不是单纯的技术活，而是一次管理挑战。它考验的不是你会不会敲命令，而是你有没有把兼容性、性能、回滚、监控这些环节串成一条完整的链路。很多团队觉得升级就是“导出‑导入‑改配置”三步走，结果往往在细节上翻车。比如字符集、索引选择、甚至时区设置，每个小问题都能让你加班到凌晨。下次如果有人问我要不要升 MySQL 8，我会先反问：你愿意为这次迁移准备多少套回滚方案？如果答案只有一套或根本没有，那还是再等等吧。
