MySQL慢查询突增需系统性排查：先验证日志开关与阈值，统计近期数量并对比监控趋势；再分层检查锁等待、索引失效、数据分布突变、并发激增等诱因；最后聚焦TOP SQL用EXPLAIN分析执行计划，结合临时缓解与长期治理措施。
MySQL慢查询突然变多，说明数据库负载或执行效率发生了明显变化，不能只盯着单条SQL优化，要系统性排查。核心思路是：先定位现象、再分层归因、最后针对性解决。
快速确认慢查询是否真实增长
别凭感觉判断，用命令验证：
- 查当前慢查询日志开关和阈值：show variables like 'slow_query_log'; 和 show variables like 'long_query_time';
- 查最近慢查询数量：SELECT COUNT(*) FROM mysql.slow_log WHERE start_time > NOW() - INTERVAL 1 HOUR;（需开启慢日志表存储）
- 对比历史趋势：如果有监控系统（如Prometheus+Grafana），直接看 slow_queries/sec 曲线是否突增
分层排查常见诱因
慢查询增多往往不是SQL本身变慢，而是外部条件恶化：
- 锁等待加剧：用 SHOW PROCESSLIST; 查看大量线程处于 Waiting for table metadata lock 或 Sending data 状态，说明有长事务或DDL阻塞
- 索引失效扩散：某张高频表的索引被误删、统计信息过期（ANALYZE TABLE 可刷新），导致大量原本走索引的查询退化为全表扫描
- 数据分布突变：例如订单表某天涌入千万级新数据，但未及时更新分区策略或未重建索引，导致WHERE条件选择率骤降
- 并发连接激增：应用未正确复用连接，或突发流量导致连接数逼近 max_connections，引发排队等待
聚焦高频慢SQL做深度分析
从慢日志中提取TOP 5耗时SQL，逐条用EXPLAIN检查：
- 看 type 字段：出现 ALL 或 index 说明没走有效索引
- 看 rows 估算值：远超实际返回行数，说明过滤条件未生效或索引列顺序不合理
- 看 Extra 字段：含 Using filesort 或 Using temporary 表示排序/分组未利用索引
- 特别注意 key 是否为NULL：即使有索引，也可能因隐式类型转换、函数包裹（如 WHERE DATE(create_time) = '2025-12-20'）导致失效
临时缓解与长期治理并行
线上问题要快准稳：
- 紧急止血：对已知高危SQL加 SQL_NO_CACHE（仅限MySQL 5.7及之前），或临时限制其并发（如应用层加熔断）
- 快速修复：对缺失索引的WHERE字段补建索引；对大IN列表改用临时表JOIN；对复杂报表查询加覆盖索引
- 长效机制：在CI/CD流程中加入SQL审核（如使用pt-query-digest分析预发慢日志）；设置慢查询告警（如超过5条/分钟触发企业微信通知）；定期执行 OPTIMIZE TABLE 清理碎片
