MySQL性能问题排查指南：从慢查询日志入手，精准定位数据库响应变慢根源
第一步：开启并分析慢查询日志，而非盲目使用EXPLAIN
当线上数据库出现响应延迟时，许多开发者会直接对SQL语句进行EXPLAIN分析。然而，慢查询日志才是记录真实性能问题的“第一现场”，它提供了已发生慢查询的客观数据，而非执行计划的理论推演。据统计，绝大多数MySQL性能瓶颈的根源，都源于未使用索引或执行时间过长的SQL语句。
开启慢查询日志进行临时排查非常便捷，仅需执行两条核心命令：首先，SET GLOBAL slow_query_log = 1以激活日志记录功能；其次，设置一个合理的敏感阈值，例如SET GLOBAL long_query_time = 0.5（单位：秒）。请注意一个关键细节：MySQL的计时采用截断方式，而非四舍五入。这意味着超过500毫秒的查询将被记录，但毫秒级的细微波动则不会。
- 日志文件路径确认：无需猜测日志存储位置，直接执行
SHOW VARIABLES LIKE 'slow_query_log_file'即可准确获取。 - 慎用未使用索引查询记录：参数
log_queries_not_using_indexes不建议长期开启。它会将所有未走索引的查询（即使仅扫描几行数据）全部记录，极易在短时间内导致日志文件膨胀并耗尽磁盘空间。 - 高效分析工具推荐：分析日志时，优先使用官方工具提升效率。例如，执行
mysqldumpslow -s t -t 10 /var/lib/mysql/mysql-slow.log，可以按总耗时降序列出前10条最慢的SQL语句，效率远超人工查阅。 - 配置持久化须知：通过
SET GLOBAL进行的参数调整在MySQL服务重启后会失效。若需永久生效，必须修改my.cnf（或my.ini）配置文件并重启MySQL服务。但在生产环境中需谨慎评估，因为慢查询日志本身也会产生额外的I/O开销。
第二步：监控Threads_running，快速识别数据库并发压力
当数据库出现“卡顿”感知时，Threads_running状态变量比查看满是Sleep状态的SHOW FULL PROCESSLIST结果更为直接和灵敏。它仅统计当前正在实际执行查询的线程数，是衡量数据库实时并发负载的核心指标。
执行SHOW GLOBAL STATUS LIKE 'Threads_running'进行监控。若该值持续高于32，则需引起警惕；若长期超过64，通常表明CPU资源或锁竞争已接近瓶颈。此时，应结合SHOW GLOBAL STATUS LIKE 'Threads_connected'（总连接数）进行对比分析：
- 若
Threads_connected（总连接数）远大于Threads_running（运行线程数），表明大量数据库连接处于空闲状态。问题根源很可能在于应用层，例如连接池配置不当或连接未及时释放。 - 若两者数值接近且均持续处于高位，则应重点检查
Innodb_row_lock_waits（行锁等待次数）与Innodb_buffer_pool_reads（从磁盘读取的页数）等指标，排查锁竞争或缓冲池命中率问题。 - 避免仅关注
PROCESSLIST中State = 'Sending data'的线程，此状态可能仅表示正在进行全表扫描。真正导致系统阻塞的，往往是那些持有锁且长时间未提交的事务。
第三步：使用iostat诊断磁盘I/O，避免误判CPU瓶颈
在top命令中观察到mysqld进程的CPU使用率偏高，并不一定代表其正在进行密集计算。对于采用InnoDB存储引擎的MySQL而言，这常常是一种“I/O等待”造成的假象：线程因等待磁盘I/O响应而被阻塞，CPU处于空闲可运行状态，但top仍会将其标记为R（运行中）。
因此，诊断I/O瓶颈更可靠的方法是直接观察磁盘性能指标。执行iostat -x 1 5命令，重点关注以下两列数据：
%util（设备利用率）：若该值持续接近100%，表明磁盘设备已无空闲时间，I/O完全饱和。await（平均I/O等待时间）：单位为毫秒(ms)。对于SSD，若超过10ms；对于HDD，若超过30ms，通常意味着存储层响应缓慢。可能原因包括云盘性能配额耗尽或网络存储（如NFS）出现抖动。- 常见陷阱识别：当
%util不高但await却异常高时，不应首先调整MySQL参数，而应检查底层基础设施。例如，RAID卡缓存电池是否失效？云服务商是否正在进行后台快照操作？ - 参数配置影响：即使磁盘本身不繁忙，若MySQL参数
innodb_io_capacity设置过低，也会限制后台刷脏页（Flush）的速率。这将导致缓冲池命中率下降，逻辑读请求激增，最终反而推高CPU使用率。
第四步：解读Handler_read_rnd_next，洞察回表与全表扫描
Handler_read_rnd_next是一个极具价值但常被忽视的状态变量。它比EXPLAIN结果中的rows预估行数更能真实反映SQL查询的物理扫描成本。该计数器记录了“通过索引定位后，再次随机读取数据行”的次数。其数值若持续偏高，强烈暗示查询存在严重的回表操作或正在进行全表扫描。
通过SHOW GLOBAL STATUS LIKE 'Handler_read%'命令查看相关计数器，分析时请关注以下关键比值：
Handler_read_rnd_next / Handler_read_next > 0.1：这通常表明查询缺少覆盖索引支持。可能是SELECT字段过多，或者是联合索引的字段顺序未能满足查询条件的最左前缀匹配原则。Handler_read_first持续增长：这往往暗示存在大量未利用索引的ORDER BY或GROUP BY操作，导致额外的文件排序（Filesort）。此时，应考虑为排序字段创建合适的索引。- 执行计划与真实成本的差异：即使
EXPLAIN显示type = ref且key字段有值（使用了索引），只要Handler_read_rnd_next很高，就说明优化器虽然选择了索引，但为了获取索引中未包含的字段，不得不频繁回表查询数据行——性能依然会严重受损。 - 性能优化黄金法则：针对高频查询，应竭力实现“覆盖索引”，即让SELECT查询的所有字段都包含在联合索引中。务必避免使用
SELECT *或查询额外的、不在索引中的字段，从而消除不必要的回表开销。
最后需要明确，导致MySQL性能急剧下降的，往往并非单一的超慢SQL。更多情况下，是多个中等耗时查询的叠加效应、事务间的锁等待链式传导，或是缓冲池等核心参数配置不当所引发的一系列连锁反应。因此，在排查性能问题时，切忌孤立地深究某条SQL的EXPLAIN执行计划。更有效的策略是，将Threads_running（并发压力）、Handler_read_*系列状态（扫描模式）、iostat磁盘指标（I/O负载）以及慢查询日志（具体慢SQL）这四条线索进行关联分析，综合判断它们是否共同指向同一个根本原因，从而实现精准、高效的MySQL性能问题定位与优化。
