mysql版本迁移中的分布式数据库架构调整与优化

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 新特性”有用得多。