ProxySQL升级需避免连接中断，核心是冗余+灰度+状态隔离：用systemd管理进程并配置自动重启，通过端口转发过渡，升级期间保持mysql_servers表中节点ONLINE状态及权重不变，确保流量不中断、路由不跳变。
不影响读写分离的代理层和底层节点升级，核心是“流量不中断、路由不跳变、一致性不破”。直接重启 Proxy 或主从节点必然导致连接断开或路由错乱，必须靠冗余+灰度+状态隔离来兜底。
ProxySQL 升级时如何避免连接中断？
ProxySQL 本身无状态，但客户端连接会因进程重启而重连，若未配置重试或连接池自动恢复，应用会出现短暂报错（如 Connection refused 或 Lost connection to MySQL server）。
- 用 systemd 或 supervisor 管理 ProxySQL 进程，启用
Restart=on-failure并设置StartLimitIntervalSec=0防止频繁崩溃被禁启 - 升级前先停掉旧实例的监听端口（如
mysql -u admin -padmin -h127.0.0.1 -P6032 -e "UPDATE global_variables SET variable_value='0.0.0.0:6033' WHERE variable_name='mysql-server_version'; FLUSH VARIABLES;"），再启动新版本监听原端口（6033 → 6032），用 iptables 或 socat 做端口转发过渡 - 关键：升级期间保持
mysql_servers表中后端节点状态为ONLINE，且hostgroup权重不变；否则 ProxySQL 重启后会清空运行时配置，需手动LOAD MYSQL SERVERS TO RUNTIME
MySQL 主从节点滚动升级时，ProxySQL 如何识别新旧版本？
ProxySQL 不感知 MySQL 版本号，只依赖 mysql_servers 表中的 status 和 weight。若升级中某从库因参数不兼容启动失败，它会被自动标记为 SHUNNED，流量立刻切走——这既是保护机制，也是隐患来源。
- 升级前在从库上执行
SELECT VERSION();和SHOW GLOBAL VARIABLES LIKE 'protocol_version';，确认新旧版本协议兼容（如 8.0.33 与 8.0.39 兼容，但 5.7 与 8.0 不互通） - 升级单个从库时，先在 ProxySQL 中将其
weight设为 0：UPDATE mysql_servers SET weight=0 WHERE hostname='old_slave_ip'; LOAD MYSQL SERVERS TO RUNTIME;，等新版本启动并同步完成后再调回 - 主库切换前，务必检查
SHOW SLAVE STATUS\G中Retrieved_Gtid_Set和Executed_Gtid_Set是否一致，否则 ProxySQL 路由事务读时可能跨节点不一致
为什么升级后 SELECT 查询突然变慢？
常见于 MySQL 8.0 升级后未调整 optimizer_switch 或统计信息陈旧，ProxySQL 的查询规则仍匹配，但执行计划劣化，导致原本走从库的慢查询拖垮整个 hostgroup。
- 升级后立即在每台 MySQL 节点上执行
ANALYZE TABLE（尤其大表），避免优化器沿用 5.7 时代的过时统计 - 检查 ProxySQL 的
mysql_query_rules是否含模糊规则（如match_digest = '^SELECT'），这类规则会把带子查询或 CTE 的 SELECT 也强制路由到从库，而新版本下这些语句可能更依赖主库索引 - 监控
stats_mysql_query_rules表中hits字段，若某条规则 hit 暴增但延迟上升，说明该规则正在误伤高成本读请求
真正难的不是命令怎么敲，而是每次升级前得确认三件事：ProxySQL 的 runtime 和 memory 配置是否已同步、所有后端 MySQL 的 read_only 状态是否按角色严格对齐、以及应用连接串里有没有硬编码 master 或 slave 别名——这些地方一漏，升级就变成故障演练。
