MySQL慢查询排查优化实战指南

数据库变慢是运维和DBA最常遇到的问题，但这类问题排查往往没有明确方向，容易盲目猜测导致效率低下，甚至引发新的生产问题。本文梳理了一套从定位问题到验证优化的完整闭环排查方法，针对MySQL 5.7和8.0的版本差异也做了明确说明，方法主要基于主流的InnoDB存储引擎展开。

排查的整体流程为：先通过慢查询日志或SHOW PROCESSLIST定位问题SQL，再用EXPLAIN分析执行计划找到原因，在测试环境验证索引优化方案，最后在生产环境审慎实施并做好回滚预案。排查前需要先判断是全局性变慢还是局部性变慢，全局性问题优先排查资源层面问题，局部问题优先分析具体SQL执行计划。

开启慢查询日志需要先手动配置，可以在线动态开启，也可以写入配置文件持久化。long_query_time一般以1秒为排查起点，可根据业务需求调整。开启后推荐使用mysqldumpslow或pt-query-digest对日志做汇总分析，重点关注单次耗时过长和执行频次高的SQL。如果问题正在发生，可直接通过SHOW PROCESSLIST查看当前会话状态，定位锁等待或正在执行的慢查询。

定位到问题SQL后，通过EXPLAIN分析执行计划判断问题，重点关注type、key、rows等核心字段。MySQL 8.0还可以使用EXPLAIN ANALYZE得到更精确的实际执行信息，但生产环境使用需要谨慎评估成本。常见优化场景为补充合适的联合索引，联合索引的字段顺序建议将区分度高、等值查询频率高的字段放在前面，优化后需要重新验证执行计划和实际耗时。生产环境创建索引推荐使用ALGORITHM=INPLACE, LOCK=NONE降低锁表风险。