MySQL慢查询怎么排查？慢日志、EXPLAIN、索引与容量分析指南

先给结论：MySQL慢不应先靠加CPU或内存猜测。先找到“哪条SQL在什么时间、扫描了多少行、返回多少行、是否等待锁”，再用EXPLAIN、索引和资源指标确认瓶颈。优化后的标准也不是命令执行成功，而是相同业务条件下响应时间、扫描行数和资源消耗下降。

本文更新时间：2026年8月22日。生产环境启用或调整日志前，应评估磁盘空间、日志轮转和隐私风险，避免把敏感参数长期写入日志。

慢查询排查需要哪些证据？

推荐的排查顺序

1. 定位业务请求：记录URL、用户操作、请求ID和慢发生的准确时间。
2. 按时间聚合SQL：使用慢查询日志和摘要工具找出总耗时高、调用次数多或扫描行数大的语句。
3. 检查执行计划：在等价数据和参数下查看EXPLAIN；关注访问类型、rows、filtered、Extra和索引选择。
4. 检查数据分布：索引是否有选择性、组合索引顺序是否匹配过滤与排序、统计信息是否合理。
5. 检查锁和连接：长事务、未提交事务、连接池过大或过小，都可能放大延迟。
6. 与主机指标对齐：把SQL时间线与CPU、可用内存、磁盘等待和吞吐量放在一起判断。

索引优化不是“越多越好”

索引可以减少读取，但会占用空间，并增加INSERT、UPDATE和DELETE的维护成本。组合索引应围绕实际查询模式设计；重复索引和长期不用的索引需要审慎评估。上线索引前，应检查表大小、锁影响、DDL方式和回滚路径。

分页越深，简单的OFFSET可能扫描并丢弃大量行；复杂排序、函数包裹字段、隐式类型转换和前置通配符也可能让索引难以发挥作用。应结合执行计划和真实数据验证，而不是只改SQL外观。

如何判断该优化SQL还是升级配置？

• 少数SQL扫描行数远大于返回行数：优先优化查询和索引。
• 所有查询都因磁盘等待升高而变慢：检查缓存命中、工作集、存储性能和并发。
• CPU持续饱和且执行计划合理：再评估分担读负载、缓存、横向拆分或提升计算资源。
• 连接数暴增但有效吞吐不升：检查连接池、重试风暴和上游超时。

硬件选型可参考2核4G、4核8G与8核16G配置指南，但必须先用压测和指标证明瓶颈。需要测试环境时可查看煜钧云云服务器。

优化后的验收清单

• 相同参数和相近数据量下，P50、P95和P99响应时间符合目标。
• Rows_examined与实际返回行数的比例明显改善。
• 写入延迟、锁等待和磁盘空间没有因新增索引恶化。
• 应用正确性、排序和分页结果与修改前一致。

常见问题

慢查询日志应该一直开启吗？

可以长期使用，但要设置合适阈值、日志轮转、访问权限和容量告警。短期把阈值调得很低时尤其要评估写盘量。

EXPLAIN显示使用索引就一定没问题吗？

不一定。索引选择性差、扫描范围大、回表次数多或排序临时表都可能仍然很慢，应结合实际执行指标判断。

官方参考资料

• MySQL 8.4：慢查询日志
• MySQL 8.4：使用EXPLAIN优化查询