上周帮一个朋友迁移数据库，他公司用的是 MySQL 5.7，想升级到 8.0。我本以为这只是常规操作，结果折腾了一整天。不是技术太难，而是很多人对迁移这事儿太掉以轻心。数据库迁移就像搬家，不是把东西搬过去就完事，还得把水管、电路、网络都重新接好。MySQL 从 5.7 升到 8.0，看似只是小版本升级，实际上内部变化翻天覆地。数据字典改了，字符集默认变成 utf8mb4，密码认证插件也换了，连 SQL 解析器都重新写过。这些改动让迁移成为一个系统工程，稍不留神就会踩坑。
先说最坑人的字符集问题。MySQL 8.0 默认字符集从 latin1 变成了 utf8mb4，这听起来是好事，毕竟支持 emoji 了。但如果旧库用 latin1 存了中文，迁移过去后会出现乱码。曾有一个电商平台迁移后，用户地址里的街道名全变成了问号，客服电话被打爆。解决方法其实不复杂：迁移前先检查旧库的字符集设置，用 查一遍。如果发现字段是 latin1 但存了中文，最好先转成 utf8mb4 再迁移。还有一点，MySQL 8.0 的排序规则也变了，默认使用 ，而旧库可能是 ，这会导致排序结果不同，甚至索引失效。这个坑特别隐蔽，很多人迁移完才发现查询变慢，查半天才知道是排序规则不匹配。
密码验证插件这块也是重灾区。MySQL 8.0 默认使用 ，而 5.7 用的是 。如果用旧客户端连 8.0，直接报错 “Authentication plugin 'cachingsha2password' cannot be loaded”。很多 DBA 的第一反应是把服务端配置改回旧插件，但这并非根本解决方案。更好的做法是升级客户端驱动，例如 PHP 的 mysqlnd、Python 的 mysql‑connector‑python，都要升级到支持新插件的版本。如果实在改不了客户端，只能在创建用户时指定 ，但这等于放弃了 8.0 的安全增强，有点因噎废食。建议公司内部统一客户端版本，别因为一个老系统拖累整体升级。
再说说数据迁移的工具选择。很多人喜欢用 mysqldump，觉得简单粗暴。确实，对于几 GB 级别的小库，mysqldump 完全够用。但一旦数据量超过 50 GB，mysqldump 就会变得又慢又占内存，锁表时间长，线上业务扛不住。这时就需要使用物理备份工具，比如 MySQL 自带的 mysqlpump 或 Percona XtraBackup。XtraBackup 的优势是热备份，不锁表，速度快，适合大库。但它的坑在于备份文件需要手动恢复，而且版本必须匹配——源库是 5.7，目标库是 8.0，XtraBackup 的版本也要相应升级，否则恢复时会报错。我上次帮朋友迁移，他公司有 200 GB 数据，用 mysqldump 跑了 6 小时仍未完成，切换到 XtraBackup 后 40 分钟搞定。工具选对了，效率翻倍。
还有一个很多人忽略的点：分区表迁移。MySQL 8.0 对分区表的支持做了不少改动，之前不支持的分区裁剪现在可以用了，但同时也废弃了一些旧语法。如果旧库有大量分区表，迁移前一定要检查 SQL 语法。我见过一个悲剧：某金融公司迁移后，分区表的插入语句报错，原因是 8.0 不再支持 中的某些表达式。只能重建分区，结果数据量太大，花了三天才搞定。所以迁移前，最好用 把每个分区表的建表语句导出来，在 8.0 环境里先跑一遍测试。发现语法错误后提前改好，别等到生产环境出问题。
性能测试这块，很多人以为迁移完就万事大吉。实际上，迁移后性能可能还不如以前。原因有很多：新的优化器对某些查询会产生不同的执行计划，索引统计信息不准确导致全表扫描，甚至默认配置变化会让内存占用飙升。我建议迁移完后先跑一轮慢查询日志分析，对比 5.7 环境和新环境的慢查询。如果发现某条查询变慢，用 查看执行计划，必要时加索引或改写查询。还有一个实用技巧：迁移后先别急着上线生产，用压测工具跑几轮，比如 SysBench 或自建脚本，模拟线上流量。压测时重点关注 CPU、内存、I/O 的变化，发现异常及时调优。我上次帮朋友迁移完后，发现 CPU 使用率比原来高了 30%，查了半天发现是 没调好，默认值太小导致频繁磁盘 I/O。
说说回滚方案。很多人在迁移时信心满满，觉得一次就能成功，结果出问题只能傻眼。数据库迁移一定要留后路：在切流量之前，先做一次完整备份，而且备份要能快速恢复。我的习惯是，迁移当天先做全量备份，然后开启 binlog，记录所有增量操作。如果迁移失败，就停掉新库，把旧库恢复出来，再重放 binlog 补回增量数据。这个方案需要提前演练，否则真到紧急时刻手忙脚乱更容易出错。还有一点：迁移完成后，保留旧库至少一周，别急着删。因为有些隐藏问题可能要几天才能暴露，比如某个存储过程在 8.0 里跑得不对，或者定时任务没同步。旧库在手，心里不慌。
总结一下，MySQL 8.0 迁移不是简单的数据搬运，而是一次系统性的升级。字符集、密码插件、工具选择、分区表、性能调优、回滚方案，每个环节都可能翻车。我的建议是：别抱侥幸心理，提前做测试，小步快跑，分批迁移。如果业务允许，先在测试环境跑一个月，把坑踩一遍再上生产。毕竟数据库崩了，老板不会关心你用的是 5.7 还是 8.0，他只关心业务能不能跑。迁移这事儿，慢就是快。
