大家好，我是数据库小学妹 👋
朋友们，上个月接触到一个客户项目，线上还跑着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能力要求高，核心业务不能停的场景用这个。
| 方案 | 停机时长 | 数据安全性 | 回滚难度 | 适用场景 |
|---|---|---|---|---|
| 原地升级 | 10-30分钟 | 中等 | 很难 | 测试环境、非核心库 |
| 逻辑备份恢复 | 数小时 | 最高 | 简单 | 小库、停机窗口充足 |
| 主从滚动升级 | 接近零 | 高 | 较难 | 核心业务、不能停机 |
my.cnf配置文件：参数替换清单
不管选哪条路径，cnf配置文件都得改。8.0把一堆参数名改了，不改的话启动会报Warning甚至Error。最常见的替换：slave改成replica，master改成source，expire_logs_days换成binlog_expire_logs_seconds。
| 旧参数 | 新参数 |
|---|---|
| log_slave_updates | log_replica_updates |
| skip_slave_start | skip_replica_start |
| slave_parallel_workers | replica_parallel_workers |
| rpl_semi_sync_master | rpl_semi_sync_source |
| rpl_semi_sync_slave | rpl_semi_sync_replica |
| 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的时候踩过什么坑？评论区聊聊，说不定你的经验能帮到其他人 👇
我是数据库小学妹，咱们下篇见 👋
