应紧盯type、key、rows和Extra四个字段：type降级（如ref→ALL）、key为NULL、rows暴涨10倍以上、Extra出现Using temporary或Using filesort，是性能回退最明确信号；同时需结合possible_keys与实际查询条件判断索引选择是否合理。
EXPLAIN对比该看哪几行关键字段
直接比EXPLAIN FORMAT=JSON输出的哈希值没用，得盯住几个决定性的字段。type降级（比如从ref变成ALL）、key为空、rows预估暴涨10倍以上，这三项是性能回退最明确的信号。Extra里出现Using temporary或Using filesort也要警惕——尤其当升级前没有，升级后突然出现。
常见误判点：只看key是否非空，忽略possible_keys里有索引但没被选中。比如possible_keys显示idx_a_b和idx_a_c都可用，但key选了idx_a_b，而实际查询条件是WHERE a=1 AND c>10，这就说明优化器判断偏差了。
怎么安全地做执行计划对比
别在生产库上直接跑EXPLAIN，更别用EXPLAIN ANALYZE（它真执行）。正确做法是：
- 升级前，在压测环境或低峰期对关键SQL执行
EXPLAIN FORMAT=JSON，保存结果到文件 - 升级后，在相同数据量、相同统计信息状态下（见下一条）立即复现
- 用
jq提取关键路径比对：jq '.query_block.children[0].table.key // "null"' plan.json，避免肉眼扫长文本 - 如果SQL含变量，确保两次执行用相同参数值，否则
rows估算会因常量折叠差异失真
为什么统计信息不更新会导致EXPLAIN失真
MySQL优化器靠统计信息估算成本，升级过程不会自动触发ANALYZE TABLE。旧版统计可能还停留在半年前，新版优化器按错误分布做决策，自然选错索引或JOIN顺序。
必须手动补这一环：
- 对存储过程中高频访问的表，逐个执行
ANALYZE TABLE orders, users;，别用ANALYZE TABLE全库扫描 - 确认
innodb_stats_auto_recalc为ON，但首次升级后仍需手动触发 - 8.0+支持直方图，若业务对倾斜数据敏感（如用户等级分布极不均匀），检查
information_schema.COLUMN_STATISTICS是否已生成，类型是否为SINGLETON而非HEALTHY
optimizer_switch变动会让EXPLAIN“说谎”
同一SQL在5.7和8.0上EXPLAIN结果不同，大概率不是数据问题，而是optimizer_switch里某项默认开关变了。比如mrr=off在8.0默认关闭，但你的查询恰好适合MRR；又比如hash_join=on启用后，优化器可能放弃嵌套循环改走哈希连接，但内存不足时反而更慢。
验证步骤：
- 升级前导出
SELECT @@optimizer_switch;存为baseline - 升级后用
diff比对，重点关注带=off的项（如index_merge=on、use_index_extensions=on） - 临时开启单项测试：
SET SESSION optimizer_switch='mrr=on';，再跑EXPLAIN，观察rows是否回落 - 每次只改1–2个开关，否则无法定位是哪个开关导致变化
真正麻烦的不是参数本身，而是参数组合效应——比如index_merge=on和use_index_extensions=on同时开启时，优化器可能优先拼单列索引，反而绕过你精心设计的复合索引。这种细节，光看单条EXPLAIN输出根本发现不了。
