MySQL升级后性能下降，不是小概率事件，而是有明确技术动因的常见现象。核心问题往往不在“版本新”，而在于新旧版本在查询优化、排序机制、统计信息使用、参数默认值等方面的差异被忽略。针对性排查比盲目调参更有效。
重点查排序行为变化
MySQL 8.0.20 起废弃了 max_length_for_sort_data 参数，排序策略从“按字段大小动态选择全字段排序或row_id排序”变为统一采用更严格的内存管理方式。若原SQL依赖
ORDER BY + LIMIT且排序字段无索引，升级后可能从毫秒级退化到数秒——尤其在
SELECT *场景下更明显。此时不能只加索引，还要确认： 排序字段是否已建索引（联合索引需注意最左前缀） 查询是否真的需要全部字段（改用具体列名可绕过部分排序开销） 对比升级前后
EXPLAIN FORMAT=TRADITIONAL和
EXPLAIN ANALYZE的执行阶段耗时分布
强制刷新统计信息
优化器严重依赖表的统计信息做执行计划决策。升级过程本身不会自动触发统计更新，而旧版本采集的统计可能已失效。特别是大表批量写入后，ANALYZE TABLE 是成本最低、见效最快的修复动作：
对慢查询涉及的主表和关联表都执行一次 若使用 InnoDB，可配合innodb_stats_persistent = ON避免后续频繁失效 不建议依赖自动采样，生产环境宜在数据变更后主动触发
核对优化器开关与默认行为
MySQL 5.7 到 8.0，optimizer_switch 中多个子开关默认值已变更，例如
mrr、
use_index_extensions、
derived_merge等。某些 SQL 在旧版靠某项优化“蒙对”了执行路径，新版关闭后直接回退到嵌套循环。应： 执行
SELECT @@optimizer_switch;获取当前值 与升级前备份的配置比对，重点关注带
=on/off的项 对关键慢SQL，可临时开启可疑开关测试（如
SET optimizer_switch='mrr=on';），验证是否恢复
检查配置参数兼容性
部分参数在新版中被移除、重命名或语义调整。例如：
query_cache_type在 8.0 中彻底移除，若应用层还依赖查询缓存逻辑，会引发误判
sql_mode默认值收紧（如新增
STRICT_TRANS_TABLES），可能使隐式类型转换失败或报错
innodb_log_file_size升级时未按官方要求重建日志文件，会导致启动失败或性能异常
务必对照 MySQL 官方升级文档中的 Removed Options and Variables 和 Incompatible Change 章节逐条核查。
