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 清理碎片
