MySQL 5.7到8.0到8.4迁移实战：LTS双轨线、高危变更与零停机升级方案

大家好，我是数据库小学妹 👋

朋友们，上个月接触到一个客户项目，线上还跑着MySQL 5.7，官方早就不维护了，客户想把库升到8.0。我查了一下才发现，8.0本身也已经在2026年4月停止维护了。现在官方推荐的LTS版本是8.4，直接升到8.4才是正经事。不过5.7到8.4不能一步到位，必须先过8.0这一关。整个升级路径是5.7→8.0→8.4，等于要做两次兼容性审计。我想着不就是换个版本嘛，测试环境跑了一遍没什么问题，就在一个周五下午切了。

结果周末用户反馈说分页查询结果跟之前不一样。我一看，8.0取消了GROUP BY的隐式排序，历史SQL全变了。花了两天紧急修复，加班到凌晨。这次教训告诉我，8.0的升级远不是"装上就能用"。官方列了30多个不兼容变更，每一个都可能是定时炸弹。今天把我踩过的坑和总结的升级方案整理出来。

升级前的兼容性审计

这步绝对不能跳，我这次版本迁移就差点栽在这上面。我分三层查。先翻官方文档，Release Notes里列的30多个不兼容变更逐条过一遍，重点看废弃项和行为变更。建议打印出来对着业务SQL一条条确认。

再用mysqlcheck预检表结构：

mysqlcheck --all-databases --check-upgrade -u root -p

这个命令会报出8.0不支持的语法，比如旧的mysql_native_password认证插件。

最后用MySQL Shell的升级检查器，它会扫描100多项潜在问题：

util.checkForServerUpgrade('root@localhost:3306', 
  {targetVersion: '8.0', password: 'your_password'})

我就是靠它发现有个表名用了8.0的保留字，差点上线了才发现。

MySQL LTS与Innovation双轨线：先搞清楚该升到哪个版本

升级之前得先弄明白Oracle的版本策略。从8.0开始，MySQL分成了两条线：Innovation版本每季度更新，追求新功能但生命周期短，适合测试和尝鲜；LTS版本每两年发一个，提供长期支持，生产环境应该用这个。

8.0是在旧发布模式下推出的版本，Oracle在2023年引入LTS/Innovation双轨模式后给了它LTS定位，但它的Extended Support已经在2026年4月到期了。8.4才是第一个正式的LTS版本，官方支持到2032年。如果你还在跑8.0，也该考虑升级了。这个版本策略的变化意味着以后不会再出现5.7到8.0这种跨度巨大的升级，每次LTS之间的间隔只有两年，兼容性变更少得多，升级压力小很多。

MySQL 5.7到8.0升级：四个最容易翻车的高危变更

30多个不兼容变更里，这四个生产环境翻车率最高。

第一个：GROUP BY不再隐式排序

这是我踩的第一个坑。5.7里GROUP BY会隐式排序返回结果，很多开发不知道这点，直接拿结果顺序写业务逻辑。8.0不保证GROUP BY的返回顺序了，同样的SQL每次执行结果可能不一样。

解决办法加ORDER BY就行，但麻烦的是找出所有依赖隐式排序的老SQL。我花了半天把所有包含GROUP BY的SQL过了一遍，改了十几个。

第二个：默认字符集变了

5.7默认latin1，8.0默认utf8mb4。听起来是好事，但如果你5.7的表是latin1建的，升级后新表utf8mb4，同一个库里字符集就乱了。

更麻烦的是索引长度。utf8mb4每个字符4字节，latin1只要1字节。VARCHAR(255)加索引，latin1下255字节没问题，换utf8mb4直接飙到1020字节，超了InnoDB的767字节限制，索引建不上去。我第一次看到这个报错的时候完全没反应过来是字符集的问题。

我建议升级前统一检查字符集。另外排序规则的默认值也变了，5.7是utf8mb4_general_ci，8.0换成了utf8mb4_0900_ai_ci。如果你有5.7从库做回滚方案，这个差异会导致复制中断——5.7不认识0900_ai_ci这个排序规则（ID 255），binlog传过去直接报错。升级后建议在my.cnf里显式指定collation_server=utf8mb4_general_ci，避免主从之间排序规则不兼容。

SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_COLLATION 
FROM information_schema.TABLES 
WHERE TABLE_SCHEMA NOT IN ('mysql','information_schema','performance_schema')
ORDER BY TABLE_COLLATION;

第三个：密码认证插件变更

8.0默认认证插件从mysql_native_password换成了caching_sha2_password。老客户端驱动不支持这个插件的话，升级完直接连不上数据库。我就踩了这个坑，一个Java应用用的Connector 5.x，升级后报认证失败。

解决办法有两个。一是升级客户端驱动。二是在my.cnf里把认证插件改回去。我当时先用了第二个办法应急，心里其实不太踏实，毕竟只是把问题往后推了。

[mysqld]
default_authentication_plugin=mysql_native_password

但改回去只是临时方案，最终还是得升级驱动。

第四个：sql_mode默认值变了

5.7和8.0的sql_mode默认值都包含ONLY_FULL_GROUP_BY，但8.0移除了NO_AUTO_CREATE_USER。如果你的5.7实例之前手动关了ONLY_FULL_GROUP_BY，升级后可能会发现SQL行为变了。另外8.0里NO_AUTO_CREATE_USER这个模式直接被废弃了，配置里有它会报Warning。

建议升级前先在5.7上把sql_mode调成8.0的默认值，跑一遍测试看看哪些SQL会炸：

SET GLOBAL sql_mode='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';

看哪些SQL会报错，提前修复。

三种升级路径对比

兼容性确认没问题，接下来选怎么升。原地升级最快，在现有实例上直接执行升级命令，停机时间短。但出了问题基本只能靠备份恢复，回滚几乎不可能。测试环境用这个最方便。

逻辑备份恢复最稳妥，mysqldump导出再导入新实例。但100G的库导出加导入可能要好几个小时，适合数据量小、停机窗口够长的场景。

主从滚动升级能做到接近零停机。先升从库，验证没问题后做主从切换，再升原主库。操作最复杂，对DBA能力要求高，核心业务不能停的场景用这个。

my.cnf配置文件：参数替换清单

不管选哪条路径，cnf配置文件都得改。8.0把一堆参数名改了，不改的话启动会报Warning甚至Error。最常见的替换：slave改成replica，master改成source，expire_logs_days换成binlog_expire_logs_seconds。

还有几个已经废弃的参数直接注释掉就行：query_cache_size、query_cache_type在8.0里被移除了，不注释掉启动会报错。innodb_log_file_size和innodb_log_files_in_group被innodb_redo_log_capacity替代，建议在cnf里显式加上innodb_redo_log_capacity。

灰度切换策略

不管选哪条路，灰度切换都要做。我的做法是用ProxySQL控流量，先把读切到8.0新实例上，观察一段时间没问题再切写。

-- ProxySQL中配置读写分离
INSERT INTO mysql_servers (hostgroup_id, hostname, port) 
VALUES (10, 'new-mysql8-host', 3306);

切流量的时候要设好回滚触发条件。我定了三个指标：错误日志出现认证相关报错、慢查询数量翻倍、主从复制中断。任何一个触发，立即切回5.7。

MySQL 8.0升级后的回归验证：三件事必做

升级完先别急着收工，还有验证要做。第一件是SQL结果比对。把所有业务SQL在新环境跑一遍，确认结果一致。第二件是性能基线，用sysbench跑个对比，看看TPS和延迟有没有变化：

sysbench oltp_read_write --mysql-host=localhost --mysql-port=3306 \
  --tables=10 --table-size=100000 --time=300 run

然后盯着监控看48小时，Buffer Pool命中率、锁等待、复制延迟这三个指标重点看。我那次就是靠监控发现了一个慢查询的，之前在5.7上跑得好好的，8.0执行计划变了。

MySQL升级避坑清单：这三个坑我替你踩过了

8.0新增了一批保留字，admin、cube、rank都中招了。表名或字段名撞上直接报语法错误，升级前用mysqlcheck查一遍，该改名提前改。

5.7支持创建降序索引但实际忽略不用，8.0是真的生效。如果你的建表语句里有DESC索引，升级后查询计划可能变，性能表现不一样。建议升级后重新跑EXPLAIN。

8.0支持InnoDB表空间加密，但不是默认启用，需要手动配置keyring插件。如果你启用了加密，备份工具版本太旧的话不支持加密表空间的备份，恢复会失败。我见过有人备份的时候没问题，恢复的时候才发现不行。用了加密的话，备份工具一定要同步升级。

从8.0到8.4：跨LTS版本的升级要点

5.7到8.0是最难的一步，8.0到8.4相对平滑很多。但8.4作为新的LTS版本，也有一些变更需要注意。

认证插件的默认值又变了，8.4进一步收紧了安全策略。mysql_native_password在8.0.34就被标记废弃了，8.4直接默认禁用。如果你的应用还在用这个插件，升级后连不上数据库。应急办法是在cnf里加loose_mysql_native_password=ON，但最终还是得把认证方式迁移到caching_sha2_password。

8.4还移除了SET_USER_ID权限，这个权限通常用在存储过程和视图的DEFINER权限模拟上。如果你的业务没有显式用到，可以直接忽略；用了的话得在升级前重构逻辑。

另外8.4的Buffer Pool自适应哈希索引默认关闭了，大多数场景下这是好事（之前多少人被这个特性坑过），但如果你的业务之前靠它加速热点查询，升级后要留意性能变化。

整个升级流程和5.7到8.0基本一样：兼容性审计、选升级路径、灰度切换、回归验证。走一遍就知道了，第二次会比第一次快很多。

写在最后

这次从5.7一路升到8.4，前前后后折腾了差不多一个月。说实话最痛苦的不是技术本身，是那种"测完了觉得没问题，一上线又踩坑"的不确定性。兼容性审计那次我就差点偷懒跳过，后来想想真要跳了，上线那天晚上怕是不用睡了。

好消息是，现在MySQL已经进入LTS+Innovation双轨模式，以后每次升级的跨度不会这么大了。坏消息是，如果你还在跑5.7或者8.0，真的该动了。5.7停维护快三年了，8.0今年4月也到期了。版本迁移这条路，早走比晚走强。

你升级MySQL的时候踩过什么坑？评论区聊聊，说不定你的经验能帮到其他人 👇

我是数据库小学妹，咱们下篇见 👋