主从滚动升级不能直接停主库，否则会导致业务中断、连接失效及数据静默丢失；升级前须验证从库延迟归零、GTID一致、只读生效；代理灰度需正确配置权重与健康检查；升级后必须验证字符集、事务隔离级别和执行计划。
主从滚动升级为什么不能直接停主库
直接停主库再升级，等于主动制造业务中断。哪怕只停 30 秒，应用连接池里残留的长连接会持续报 Lost connection to MySQL server，HikariCP 或 Druid 不会自动重连已失效连接，除非配置了 connection-test-query 或触发 evictAllConnections()。更麻烦的是，如果从库 Seconds_Behind_Master > 0，你停主库那一刻还没同步的 binlog 就永远丢失——这不是升级失败，是数据静默丢失。
轮询升级从库时必须验证的三个状态
每台从库升级前，不能只看 Slave_IO_Running 和 Slave_SQL_Running 是 Yes。必须确认：
-
Seconds_Behind_Master = 0（延迟归零） -
Retrieved_Gtid_Set与Executed_Gtid_Set完全一致（用SELECT GTID_SUBSET(@@global.gtid_executed, 'xxx')=1校验） - 从库
read_only=ON且super_read_only=ON已生效（防止误写）
漏掉任意一项，升级后切为主库可能立刻引发主键冲突、唯一索引报错或事务回滚异常。
MySQL Router / ProxySQL 灰度权重切换的关键配置
靠代理层做灰度，核心不是“加一台新实例”，而是控制流量进入节奏。实操中容易忽略的点：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- ProxySQL 的
mysql_servers表里，新实例初始weight必须设为1（不是 0），否则SELECT流量根本不会发过去，健康检查也形同虚设 - HAProxy 必须开启
option mysql-check user haproxy_check，且后端 MySQL 上要提前建好该用户并授权USAGE，否则check永远返回UP，切换时流量照旧打向宕机节点 - 权重调整间隔不能低于监控采样周期，比如 Prometheus 抓取间隔是 15s，你就不能每 5s 调一次权重，否则指标抖动无法归因
升级后最易被跳过的验证动作
很多人验证完 mysqld --version 和 SELECT 1 就上线，结果第二天发现慢查询暴增。真正要跑的验证项很具体：
- 用应用实际账号执行
INSERT INTO t VALUES (1, '中文')，确认utf8mb4_0900_ai_ci排序行为没破坏业务逻辑 - 查
information_schema.INNODB_TRX，确认trx_isolation显示READ-COMMITTED（MySQL 8.0 默认），而非旧版本的REPEATABLE-READ，否则并发更新可能表现异常 - 执行
EXPLAIN FORMAT=tree SELECT * FROM t WHERE id = ?，比对升级前后是否出现Using temporary; Using filesort，这是隐式类型转换或索引失效的典型信号
这些动作不耗时，但跳过它们，等于把问题留给凌晨三点的告警电话。
