MySQL平滑升级核心是“先加新、再切流、后下线”，需遵循官方路径（如5.7→8.0.33+），验证兼容性、主从滚动升级、代理灰度发布及升级后全链路验证，确保业务无感、数据不丢、服务不断。
MySQL 平滑升级的核心是“先加新、再切流、后下线”，不中断服务，不丢失数据，不改变应用逻辑。关键不在版本本身，而在升级路径设计和状态验证机制。
一、确认兼容性与升级路径
MySQL 不支持跨大版本直接升级（如 5.7 → 8.0），必须遵循官方推荐路径：5.7 → 8.0.33+（推荐最小跳转版本），或分步经中间版本。需重点检查：
- SQL 模式变化（如 STRICT_TRANS_TABLES 在 8.0 中默认启用，可能触发旧 SQL 报错）
- 废弃语法（mysql.user 表结构变更、GRANT 语句不再支持 IDENTIFIED BY 语法）
- 字符集默认值（8.0 默认 utf8mb4_0900_ai_ci，应用连接未显式指定时可能影响排序行为）
- 认证插件变更（caching_sha2_password 成为默认，老客户端需升级或配置 fallback）
二、采用主从滚动升级（推荐线上主流方案）
适用于主从架构（含 MHA / Orchestrator 等高可用组件），全程业务无感知：
- 先升级所有从库：停掉一个从库 → 备份数据目录（可选）→ 替换二进制 + 配置文件 → 初始化或直接启动（若数据格式兼容）→ 启动复制并验证 Seconds_Behind_Master = 0
- 逐台轮换，确保至少一台从库始终可用作故障切换源
- 最后升级主库：通过高可用工具执行主从切换（如 orchestrator client -c relocate-replicas），将流量切到已升级的从库，原主库降为从库后再升级
三、使用 MySQL Ro
uter 或代理层解耦应用依赖
若架构中已部署 MySQL Router、ProxySQL 或 MaxScale，可利用其读写分离与后端权重能力实现灰度：
- 新增升级后的实例，加入后端集群，初始权重设为 0
- 逐步调高权重（如每次 +10%），同时监控慢查询、错误率、连接数
- 观察应用日志与监控指标（QPS、延迟、Aborted_clients）稳定 30 分钟以上再继续
- 旧实例权重归零且确认无流量后，再下线
四、升级后必做的验证动作
不能只看“能连上、能查数据”，要覆盖真实业务链路：
-
权限校验：用应用账号执行典型 DML（INSERT/UPDATE/SELECT/FOR UPDATE）和 DDL（ALTER TABLE ADD COLUMN）
-
事务一致性：模拟并发更新同一行，验证隔离级别表现是否符合预期（尤其 READ-COMMITTED 在 8.0 的优化）
-
备份恢复验证：用新版本 mysqldump 或 xtrabackup 备份，再恢复到临时实例，执行一致性比对（pt-table-checksum）
-
慢日志回归：对比升级前后相同 SQL 的执行计划（EXPLAIN FORMAT=tree），警惕隐式类型转换或索引失效
平滑不是靠一次操作完成，而是靠分阶段控制、可观测性和回滚预案。只要主从同步正常、应用连接池支持自动重连、备份完整，整个过程可以做到用户无感。
uter 或代理层解耦应用依赖