MySQL升级后慢查询增多主因是隐患暴露或配置重置，需优先验证慢日志启用状态、关键参数（slow_query_log、long_query_time等）、实时抓取高耗时SQL，并聚焦扫描行数远大于返回行数、全表扫描、高频低耗时三类高危查询，同时对比新旧版本执行计划及更新统计信息。
MySQL升级后慢查询变多，大概率不是“突然变慢”，而是原有隐患被暴露或配置被重置。重点不在修复单条SQL，而在快速定位变化点、验证关键配置、聚焦高影响查询。
确认慢查询日志是否真正启用
升级常导致配置回退到默认值，必须手动检查：
- 登录 MySQL 执行 SHOW VARIABLES LIKE 'slow_query_log'; —— 若返回 OFF，日志根本没开
- 执行 SHOW VARIABLES LIKE 'slow_query_log_file'; —— 确认路径可写，避免日志静默丢弃
- 执行 SHOW VARIABLES LIKE 'long_query_time'; —— 升级后可能仍为默认 10 秒，建议设为 2 或 0.5（视业务敏感度）
- 在 my.cnf 中补全并重启：添加 slow_query_log = ON、long_query_time = 2、log_queries_not_using_indexes = ON（测试环境可用，生产慎开）
不依赖日志的实时快筛方法
等日志积累再分析太慢，升级后应立刻抓当前活跃瓶颈：
- 运行 SHOW PROCESSLIST; 或查 sys.session 视图，重点关注 State 为 Sending data、Copying to tmp table、Sorting result 且 Time 值偏高的连接
- 用 SELECT * FROM sys.statement_analysis ORDER BY avg_timer_wait DESC LIMIT 10; 直接列出平均耗时最高的 SQL 模板（自动去参数化，更贴近真实分布）
- 结合 information_schema.PROFILING（若开启）对可疑语句做单次执行阶段耗时分解
聚焦三类高危查询优先处理
不用通读全部日志，先锁定以下特征的 SQL（占慢查询 80% 以上）：
- 扫描行数远大于返回行数：如 rows=100000 但 sent_rows=1，大概率缺索引或索引失效
- 未使用索引却走全表扫描（type=ALL）：用 EXPLAIN 验证，注意隐式类型转换、函数包裹字段（如 WHERE DATE(create_time) = '2025-12-01'）会跳过索引
- 高频低耗时但总耗时占比高：比如某条 50ms 的 SQL 每秒执行 200 次，每小时就吃掉 360 秒 CPU —— 用 mysqldumpslow -s c -t 5 slow.log 查调用次数 Top5
验证升级是否引发执行计划变更
同一 SQL 在新旧版本可能走不同索引，这是升级后慢查询激增的常见原因：
- 对典型慢 SQL，分别在新旧实例上执行 EXPLAIN FORMAT=TRADITIONAL + SQL，对比 key、rows、type、Extra 字段
- 检查 optimizer_switch 设置是否有调整（如 upgrade 后默认启用了 block_nested_loop），必要时用 /*+ USE_INDEX(...) */ 临时固化索引
- 留意统计信息是否陈旧：ANALYZE TABLE 表名; 更新行数和索引分布，避免优化器误判
