MySQL平滑升级核心是通过主从切换、数据同步和角色轮换实现无感知服务连续性。先升从库并验证兼容性，再低峰期切换主从；结合中间件灰度路由或双主热备隔离升级，全程需关注字符集、权限、SQL模式等细节并备妥回滚方案。
MySQL 平滑升级（即无停机升级）的核心思路是避免主库直接升级，转而通过架构切换、数据同步和角色轮换来实现服务不中断。关键不在于“能不能不停机”，而在于“如何让业务感知不到停机”。
主从切换 + 新版本从库升级
这是最常用、风险最低的方案。前提是已有主从架构（推荐 GTID 模式）：
- 先在从库上部署新版本 MySQL（如 5.7 → 8.0），并配置好复制，确保数据实时追平
- 对新从库做兼容性验证：检查 SQL 语法、字符集、认证插件（caching_sha2_password）、系统表结构等是否适配应用
- 业务低峰期执行主从切换：将原主库设为只读，提升新版本从库为主库，原主库降为新从库（需确认 8.0→5.7 复制是否允许；通常不推荐反向复制，建议后续逐步下线旧版本节点）
- 切换后观察监控指标（QPS、延迟、错误率、慢查询）及业务日志，确认无异常再推进后续节点升级
中间件路由层配合灰度切换
若使用了 Proxy（如 MyCat、ShardingSphere-Proxy）或云数据库网关（如阿里云 DMS、腾讯云 DBProxy），可利用其读写分离与动态路由能力：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
- 将新版本实例加入集群，但初始路由权重设为 0（不转发流量）
- 逐步调高只读请求权重，验证新版本稳定性与性能表现
- 写请求切换前，确保主库已升级完成且双写/补偿机制就绪（如 binlog 解析回写或应用层事务兜底）
- 整个过程对应用透明，只需中间件配置变更，无需改代码或重启服务
双主热备 + 版本隔离升级
适用于对可用性要求极高、能接受一定运维复杂度的场景（注意：双主需严格规避自增冲突、唯一键冲突）：
- 搭建两套独立主库（A 和 B），均开启 GTID 和半同步，互为备份但不互相复制
- 先停 A 的写入（切到 B），升级 A 实例至新版，恢复 A 的复制链路并校验数据一致性
- 再切写入到 A，停 B 写入，升级 B；完成后恢复双活或按需保留单主
- 全程由接入层（如 HAProxy、应用配置中心）控制写入路由，秒级生效
注意事项与避坑点
升级不是单纯换二进制文件，很多问题出在细节：
- 字符集与排序规则：MySQL 8.0 默认 utf8mb4_0900_ai_ci，老应用若依赖 utf8mb4_general_ci，需显式指定或升级前调整
-
权限系统变更：8.0 引入角色管理、密码历史策略，默认密码认证插件变为 caching_sha2_password，JDBC 连接串需加
allowPublicKeyRetrieval=true&serverTimezone=UTC -
SQL 模式收紧：STRICT_TRANS_TABLES 等默认启用，可能导致旧应用 insert null 到非空字段失败，建议升级前在测试环境开启
sql_mode=ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,...预检 - 备份与回滚预案：必须提前用新版本 mysqldump 或 mydumper 备份，并验证还原流程；准备好降级脚本（如快速重装旧包、导入逻辑备份）
