MySQL版本迁移本身不触发分布式架构调整，但与中间件兼容性问题常导致同步升级；需关注认证插件、SQL模式、GTID、索引优化及中间件版本适配等细节。
MySQL 版本迁移本身不直接触发分布式数据库架构调整——那是业务扩展、分库分表策略演进或中间件升级带来的结果。单纯从 5.7 升级到 8.0，或从 8.0.28 升级到 8.0.33，你不需要重设计分片逻辑、改写路由规则、替换 ShardingSphere 或 MyCat 配置。但现实里，这两件事常被绑在一起做，因为旧版本 MySQL + 旧版分库中间件组合往往存在兼容性断层。
MySQL 8.0 对分布式中间件的兼容性冲击点
升级到 8.0 后，ShardingSphere-JDBC 4.x 或 MyCat 1.6 可能连接失败、预编译语句报错、权限校验异常。根本原因不是 MySQL “变慢了”，而是 8.0 默认启用 caching_sha2_password 插件、移除了 mysql_old_password 支持、收紧了 sql_mode（如默认含 STRICT_TRANS_TABLES），且 information_schema 表结构有细微变更。
- Java 应用连不上：检查 JDBC URL 是否带
?serverTimezone=UTC&allowPublicKeyRetrieval=true&useSSL=false，驱动版本必须 ≥8.0.28 -
ShardingSphere-Proxy 5.3+才完整支持8.0.32+的认证协议；5.2.x在执行SHOW CREATE TABLE时可能解析失败 - 若用
max_allowed_packet做分页合并，注意8.0默认值从4MB降为4MB（表面没变），但实际受net_buffer_length
影响更敏感，大结果集易触发
Packets larger than max_allowed_packet
分库键（sharding key）在 8.0 下的索引效率变化
8.0 的 cost-based optimizer（CBO）对联合索引中分库键位置更敏感。比如原 ORDER BY user_id, create_time 在 5.7 走 (create_time, user_id) 索引勉强可用，到 8.0 可能直接跳过该索引，导致跨分片排序成本飙升。
- 所有分库键字段必须是联合索引的最左前缀，不能靠“覆盖索引”蒙混过关
-
JSON字段不再支持函数索引下推到分片节点（8.0.13+支持JSON_EXTRACT函数索引，但 ShardingSphere 不识别其下推能力） - 执行
EXPLAIN FORMAT=TREE查看是否走到了分片内索引；若显示"access_type": "table"，说明没命中索引，得调优
GTID 模式对分片集群主从切换的影响
启用 gtid_mode=ON 是 8.0 推荐做法，但它会让分片中间件的主从路由逻辑更脆弱。例如 ShardingSphere 的读写分离模块依赖 SHOW SLAVE STATUS 中的 Exec_Master_Log_Pos 判断延迟，而 GTID 下该字段恒为 0，必须切到 Retrieved_Gtid_Set 和 Executed_Gtid_Set 差值判断——老版本中间件压根不读这两个字段。
- 升级前确认中间件文档是否标注 “GTID-aware”；未标注则默认不安全
- 不要在 GTID 开启状态下执行
CHANGE MASTER TO ... MASTER_LOG_FILE类命令，会破坏 GTID 一致性，导致分片节点间 binlog 位置错乱 - 若用
mysqldump做分片数据迁移，必须加--set-gtid-purged=OFF，否则导入后 GTID_EXECUTED 不一致，主从同步中断
SET GLOBAL gtid_mode = ON; SET GLOBAL enforce_gtid_consistency = ON;
真正卡住进度的，往往不是 SQL 怎么写，而是中间件版本和 MySQL 版本之间那几行没写进 Release Note 的协议细节。上线前拿生产流量镜像在预发环境跑 72 小时，比看十篇“MySQL 8.0 新特性”有用得多。
