MySQL 升级后性能下降常见，主因是默认行为、统计信息、执行计划和配置兼容性隐性变化；需通过 EXPLAIN 对比执行计划、ANALYZE 更新统计信息、核对 sql_mode 及 innodb_buffer_pool_size 等关键配置，并检查锁等待状态。
MySQL 升级后性能下降，不是小概率事件，而是常见现象。核心原因往往不在版本本身，而在于新旧版本间默认行为、统计信息、执行计划和配置兼容性的隐性变化。重点不是“回退”，而是快速定位变化点并针对性调整。
检查执行计划是否发生意外变更
MySQL 5.7 升级到 8.0 后，优化器逻辑有明显改进（如哈希连接、窗口函数支持、直方图），但也可能让旧查询“误选”更差的执行路径。
- 对变慢的关键 SQL，立即执行 EXPLAIN FORMAT=TREE 或 EXPLAIN ANALYZE（8.0.18+ 支持），对比升级前后的执行步骤、访问行数、是否使用索引、是否触发临时表或文件排序
- 特别注意 type 字段是否从 ref 降为 ALL，key 是否为空，rows 预估是否严重偏离实际
- 若确认执行计划劣化，可临时用 USE INDEX 或 FORCE INDEX 固定索引，争取排查时间
强制更新统计信息
升级后，InnoDB 表的统计信息不会自动刷新，而 8.0 优化器更依赖准确的行数、索引基数等数据做决策。大批量写入或结构变更后，统计信息极易过期。
- 对高频查询涉及的表，运行 ANALYZE TABLE table_name;
- 批量操作（如 INSERT SELECT、大范围 UPDATE/DELETE）完成后，必须补上 ANALYZE
- 可通过 SELECT * FROM information_schema.STATISTICS WHERE TABLE_NAME = ‘xxx’; 查看索引基数是否明显异常
核对关键配置项是否被重置或不兼容
MySQL 8.0 移除了大量旧参数（如 query_cache_type），部分参数默认值也已变更（如 innodb_buffer_pool_size 默认仍为 128M，远低于生产需求）。WAMP 等集成环境常沿用旧版 my.ini，导致配置“看似生效实则失效”。
- 检查 sql_mode：8.0 默认启用严格模式（STRICT_TRANS_TABLES），可能触发 隐式类型转换 失败或警告抑制，间接影响性能
- 确认 innodb_buffer_pool_size 是否足够（建议设为物理内存的 50%–75%，但不低于 2GB）
- 留意 optimizer_switch 中是否禁用了有用特性（如 hash_join=on），或启用了实验性开关引发不稳定
- 对比升级前后 SHOW VARIABLES 输出，重点关注与缓存、排序、连接、日志相关的参数
关注锁与并发行为变化
8.0 引入了原子 DDL、改进的 MDL（元数据锁）机制和更细粒度的锁等待统计，某些场景下锁竞争表现会更“显性”。原来不明显的阻塞，在 8.0 中可能直接暴露为长时间 waiting for table metadata lock。
- 执行 SELECT * FROM performance_schema.data_locks; 和 data_lock_waits; 查看实时锁状态
- 检查 SHOW PROCESSLIST 中是否存在大量 Waiting for table metadata lock 或 Updating 状态长期挂起
- 避免在业务高峰期执行 ALTER TABLE，尤其涉及全文索引或 JSON 列的变更
