不能直接在分库分表集群上运行mysql_upgrade，因其会遍历所有分片库的元数据导致超时、中断；中间件路由依赖旧版mysql行为，升级后易出现路由错乱；mysql 8.0已移除myisam系统表支持，强制升级会报错；且升级单位应为物理实例而非逻辑库，需按节点滚动升级并同步适配中间件认证、时区、权限等配置。
大数据量场景下无法直接对单库单表做在线版本升级，必须结合分库分表架构和滚动升级策略。跨大版本（如5.7→8.0）时，原地升级必然失败；即使同大版本小版本升级，单表超千万行也会因 mysql_upgrade 扫描系统表、重建数据字典而卡住或超时。
为什么不能直接在分库分表集群上跑 mysql_upgrade
分库分表本身不改变 MySQL 实例的升级逻辑，但放大了风险点：
-
mysql_upgrade在 8.0.16+ 已被mysqld --upgrade替代，但它仍会遍历所有库的INFORMATION_SCHEMA和系统表——当有上百个分片库时，元数据加载耗时剧增，容易触发超时或连接中断 - 若使用 MyCat 或 ShardingSphere 这类中间件，其路由规则依赖 MySQL 版本行为（如 JSON 函数返回类型、隐式类型转换），
mysql_upgrade不处理中间件兼容性，升级后可能查不到分片或路由错乱 - 部分分表方案依赖
MyISAM引擎（如历史归档表），而 MySQL 8.0 已彻底移除 MyISAM 系统表支持，--upgrade=FORCE会直接报错退出
分片集群的滚动升级必须按节点而非按库执行
你管理的是物理实例集群，不是逻辑库集合。每个分片背后是一个独立 MySQL 进程，升级单位只能是 server_id 对应的实例。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 先确认所有分片是否启用 GTID：
SELECT @@gtid_mode;，未开启则无法安全切换主从，必须补开并刷出全量 binlog - 对每个分片实例，按「从库→主库」顺序升级：停该实例的 SQL_THREAD → 替换二进制 → 启动新版本 →
START SLAVE→ 等待Seconds_Behind_Master = 0→ 再切为写入节点 - 禁止跨分片并行升级：ShardingSphere 的
db-discovery或 MyCat 的心跳检测可能将尚未完成升级的节点误判为宕机，触发非预期故障转移 - 升级中若用到
pt-online-schema-change修改分片内表结构，需确保工具版本 ≥ 3.7.0（适配 MySQL 8.0+ DDL 元数据锁变化）
中间件层必须提前适配新版本语法与权限模型
MySQL 8.0 的认证插件、默认密码强度、角色权限体系变更，会直接影响中间件连接池和路由决策。
- ShardingSphere-Proxy 5.3.2+ 才完全支持
caching_sha2_password插件；旧版会报Public Key Retrieval is not allowed - MyCat 2.x 需关闭
useSSL=false并显式配置serverTimezone=UTC，否则 8.0 默认的强时区校验会导致连接复用失败 - 所有分片用户必须用
CREATE USER ... IDENTIFIED WITH mysql_native_password显式指定认证方式，避免升级后应用连不上任何分片 - 检查中间件配置中是否硬编码了
max_allowed_packet或wait_timeout，MySQL 8.0 默认值已调整，不匹配将导致大结果集截断或空闲连接被主动断开
最易被忽略的一点：分库分表不是升级的“加速器”，而是升级复杂度的“放大器”。每个分片都是一个潜在故障点，而中间件又引入一层抽象。真正可控的升级节奏，取决于你能否把「一个分片实例 + 对应中间件配置 + 应用侧连接池」打包成原子单元，并逐个验证通过。跳过任一环节，都可能在凌晨三点收到告警：某 37 号订单库路由失败，但错误日志里只显示 Unknown system variable 'sql_mode'——其实是中间件没同步更新 MySQL 8.0 的初始化变量白名单。
