MySQL升级需逐级进行（如5.7→8.0→8.1），规避语法变化、默认行为调整、弃用功能移除三类风险；须提前检查兼容性、分阶段灰度升级，并重点适配认证插件、密码策略、JSON索引等关键变更。
MySQL 升级时的版本兼容问题，核心在于语法变化、默认行为调整、弃用功能移除这三类风险。不做好兼容性评估和过渡安排，容易导致应用报错、查询结果异常甚至服务中断。
明确升级路径与支持周期
MySQL 官方不支持跨大版本直接升级（如 5.7 → 8.0），必须逐级升级（5.7 → 8.0 → 8.1）。同时注意：
- MySQL 5.7 已于 2023 年 10 月结束生命周期（EOL），不再接收安全更新，建议尽快迁移
- MySQL 8.0 是当前长期支持（LTS）版本，8.1 起为滚动发布，生产环境优先选 8.0.x（如 8.0.33+）
- 查看官方文档中的 “Upgrading MySQL” 章节，确认目标版本对当前版本的升级要求（如是否需先升级到中间版本）
提前执行兼容性检查
在正式升级前，用工具和人工方式识别潜在冲突：
- 使用 mysql_upgrade（旧版）或 mysqld –upgrade=FORCE（8.0+）前，先运行 mysqlcheck –check-upgrade 扫描表结构兼容性
- 启用 sql_mode 中的
STRICT_TRANS_TABLES和ONLY_FULL_GROUP_BY（8.0 默认开启），在旧版本中提前测试，暴露松散 SQL 的隐患 - 检查应用代码中是否使用了已废弃语法：如
CREATE TEMPORARY TABLE ... TYPE=MyISAM（应改用 ENGINE）、GROUP BY隐式排序、无引号的保留字作列名等 - 导出所有存储过程、函数、触发器，用 mysqldump –no-data –routines –triggers 检查语法是否通过 8.0 解析
分阶段灰度升级策略
避免全量一次性切换，降低故障影响面：
- 先升级从库：将新版本 MySQL 部署为只读从库，同步主库数据，观察复制延迟、错误日志及慢查询变化
- 切读流量：通过代理（如 ProxySQL、MaxScale）或应用配置，将部分读请求路由至新版本从库，验证业务逻辑正确性
-
主库升级前备份元数据：执行
mysqldump --no-data --all-databases > schema_backup.sql，并记录SELECT VERSION(), @@sql_mode, @@default_authentication_plugin; -
主库停写升级：选择低峰期，停止写入、等待复制追平、执行原地升级（或替换二进制）、运行
mysql_upgrade（若需要）、重启验证
关注关键行为变更项
这些改动极易引发隐性故障，需重点适配：
-
认证插件变更：8.0 默认使用
caching_sha2_password，老客户端（如 MySQL 5.7 客户端、部分 JDBC 驱动）可能连接失败；解决方法：升级驱动、或创建用户时显式指定IDENTIFIED WITH mysql_native_password -
密码过期策略默认开启：
default_password_lifetime = 0可关闭，或定期调用ALTER USER ... PASSWORD EXPIRE NEVER -
JSON 字段索引语法不同：5.7 用虚拟列 + 普通索引，8.0 支持直接
CREATE INDEX ON t (doc->"$.field")，升级后建议重构以提升性能 -
系统表重构：8.0 将权限表（user、db 等）迁至
mysql库的 InnoDB 表，不再支持 MyISAM；升级后勿直接操作这些表，统一用GRANT/CREATE USER
不复杂但容易忽略。关键是把兼容检查做在升级前，把验证做在切流前，把回滚方案写在升级脚本里。