升级后需检查执行计划变化，使用EXPLAIN分析访问类型、索引选择、扫描行数及Extra提示；更新统计信息ANALYZE TABLE；评估索引有效性，创建覆盖索引或复合索引；必要时用Hint临时指定索引；对比optimizer_switch等参数差异，确保优化器正确决策。
MySQL升级后，查询执行计划可能发生变化，这通常是因为优化器逻辑、统计信息收集方式或索引选择策略的改进。要确保查询性能不降反升，需要主动检查并优化查询计划。以下是几个关键步骤和建议。
检查执行计划是否变化
使用 EXPLAIN 或 EXPLAIN FORMAT=JSON 查看升级前后查询的执行路径。重点关注以下几点：
- 访问类型（type）：是否从 ref 变成 ALL（全表扫描）？理想情况是 range、ref 或 const。
- 使用的索引（key）：是否选择了更合适的索引？有时新版本会换用不同索引，需验证其效率。
- 扫描行数（rows）：预估行数是否显著增加？这可能意味着索引失效或统计信息不准。
- Extra 字段：出现 Using filesort、Using temporary 等提示时，说明存在性能隐患。
更新表的统计信息
MySQL 8.0 后默认自动收集统计信息，但升级后旧表可能仍使用过时的统计。手动触发更新可提升执行计划准确性：
ANALYZE TABLE table_name;对大表可考虑设置 innodb_stats_persistent_sample_pages 提高采样精度，避免因统计偏差导致错误索引选择。
评估并调整索引
升级后某些查询可能不再走预期索引，原因包括：
- 优化器认为全表扫描更快（如结果集占比高）
- 索引未覆盖查询字段，回表成本变高
- 隐式类型转换或函数操作导致索引失效
建议：
- 为高频查询创建覆盖索引，减少回表
- 检查 WHERE、ORDER BY、GROUP BY 中的字段组合，设计复合索引
- 删除长期未使用的冗余索引，降低维护开销
利用优化器提示（Hint）临时控制执行计划
若发现某查询在新版本中执行变慢，可用 Hint 强制使用特定索引：
SELECT /*+ USE_INDEX(table_name idx_col) */ * FROM table_name WHERE col = 1;注意：Hint 是临时手段，应结合分析根本原因，比如统计信息、索引设计或参数配置问题。
检查优化器相关参数变化
不同 MySQL 版本默认参数可能不同，影响执行计划。关注以下变量：
- optimizer_switch：查看是否启用了 index_merge、semijoin、materialization 等特性
- eq_range_index_dive_limit：影响等值范围扫描的精确性
- use_index_extensions：InnoDB 是否使用索引扩展
可通过对比升级前后参数值，判断是否需手动调整。
基本上就这些。升级后系统整体表现更优，但个别查询可能因优化器“ smarter ”而走偏。定期审查慢查询日志，配合 EXPLAIN 分析，及时调整索引和统计信息，才能让查询计划真正高效起来。
