MySQL升级后出现慢查询问题，通常是因为新版本的优化器行为、配置参数变更或索引统计信息变化导致执行计划改变。处理这类问题需要系统性地排查和优化，以下是具体方法。
检查并更新统计信息
MySQL 5.6以后版本对索引和表的统计信息更加依赖，升级后若未及时更新，可能导致优化器选择错误的执行计划。
运行 ANALYZE TABLE 表名; 更新表的统计信息 对大表可设置 innodb_stats_persistent = ON 确保统计信息持久化 检查 information_schema.TABLES 中的统计信息是否准确对比执行计划变化
升级前后执行计划可能不同，需使用 EXPLAIN 分析关键查询。
对慢查询语句使用 EXPLAIN FORMAT=JSON 获取详细执行信息 关注 type、key、rows、filtered、Extra 字段判断是否走索引 对比升级前后执行计划差异，确认是否出现全表扫描或索引失效调整SQL语句与索引设计
部分SQL在新版本中可能不再高效，需重新评估索引和写法。
为 WHERE、ORDER BY、GROUP BY 字段建立复合索引，避免回表 避免使用函数包裹字段（如 WHERE YEAR(create_time) = 2023） 拆分复杂查询，减少 JOIN 数量或使用临时表优化 启用 slow_query_log = ON 并设置 long_query_time = 1 捕获慢查询优化配置参数
新版本默认配置可能不适用于原有业务场景。
适当调大 innodb_buffer_pool_size（建议物理内存的70%~80%） 开启 query_cache_type = OFF（MySQL 8.0已移除，5.7建议关闭） 调整 optimizer_switch 参数，如关闭某些新优化规则测试性能影响 启用 log_queries_not_using_indexes 发现未走索引的查询基本上就这些。关键是通过慢日志定位问题SQL，结合执行计划分析原因，再从索引、语句、配置三方面入手优化。升级后建议先在测试环境验证核心SQL性能，避免上线后出现严重延迟。
