大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！

一条SQL慢，可能有一百种原因。

SQL写法有问题、索引没建对、统计信息过旧、参数没调好、磁盘I/O满了、内存不够、网络抖动……每种原因对应的排查方法完全不同。

很多DBA的做法是“先查SQL”——翻慢查询日志、看执行计划、加索引。如果运气好，问题就在SQL层，解决了。如果运气不好，折腾半天发现是磁盘打满了，或者内存不够导致Swap——前面全白干。

今天讲一套“分层诊断”的思路：从SQL层→数据库层→操作系统层，逐层排查，不跳步、不瞎猜。

一、分层诊断的核心逻辑

性能问题的根因可能在任何一层。先查哪一层，决定了你要花多少时间找到答案。

分层诊断的逻辑是：

1. 先从SQL层入手——这是最直观、最容易定位的层面。如果问题在SQL层，改SQL或加索引就能解决，成本最低。

2. SQL层没问题，再看数据库层——参数配置、连接池、锁等待、缓冲池命中率。

3. 数据库层也没问题，最后看操作系统层——CPU、内存、磁盘I/O、网络。

记住这个顺序。不要一上来就查操作系统，也不要死磕SQL不放。逐层排查，效率最高。

二、第一层：SQL层——最直观的排查入口

SQL层的问题是最容易发现的，也是最容易解决的。

排查工具：

工具	用途	输出
慢查询日志	找到慢SQL	执行时间、扫描行数、锁等待时间
EXPLAIN	看执行计划	type、key、rows、filtered、Extra
EXPLAIN FORMAT=JSON	看成本估算	cost_info中的read_cost、prefix_cost
OPTIMIZER_TRACE	看优化器决策过程	完整决策链路

第一层排查清单：

• □ 慢查询日志里有没有这条SQL？
• □ 执行计划的type是不是ALL或index？
• □ rows是否远大于预期？
• □ Extra有没有Using filesort或Using temporary？
• □ 索引是否使用了？key是否为NULL？
• □ 统计信息是否过旧？rows估算值和实际行数差多少？

如果第一层排查完没问题，或者发现问题不在SQL层，进入第二层。

三、第二层：数据库层——SQL之外的问题

SQL没问题，但系统还是慢。这时候要看的不是SQL，是数据库本身。

第二层排查清单：

1. 连接与并发

SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';

如果Threads_connected接近max_connections上限，说明连接池配置不足或应用没有正确释放连接。

2. 锁等待

SELECT * FROM information_schema.INNODB_TRX WHERE trx_state = 'LOCK WAIT';

如果有事务处于LOCK WAIT状态，说明有锁竞争。找出阻塞者是谁、被阻塞的是谁、锁等待了多久。

3. 缓冲池命中率

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

命中率 = (Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests。如果低于95%，说明innodb_buffer_pool_size可能不够大。

4. 临时表创建频率

SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';
SHOW GLOBAL STATUS LIKE 'Created_tmp_tables';

如果磁盘临时表比例过高（Created_tmp_disk_tables / Created_tmp_tables > 20%），说明内存临时表不够用，需要调整tmp_table_size和max_heap_table_size。

5. 参数配置

• innodb_buffer_pool_size是否合理？（物理内存的50%-70%）

• innodb_log_file_size是否足够？（推荐1-4GB）

• innodb_flush_log_at_trx_commit是否符合业务要求？

如果第二层排查完没问题，进入第三层。

四、第三层：操作系统层——被忽略的“隐形瓶颈”

SQL没问题，数据库配置也没问题——但系统还是慢。这时候，问题可能在操作系统。

第三层排查清单：

1. CPU

• us高（>70%）→ 应用在大量计算，需要优化SQL或升级CPU

• sy高（>30%）→ 系统在频繁切换上下文，可能是连接风暴或锁竞争

• wa高（>10%）→ CPU在等磁盘，问题在I/O，不是CPU

2. 内存

free -h
vmstat 1

• available接近0 → 内存不足

• si/so非0 → 发生了Swap，性能会急剧下降

3. 磁盘I/O

iostat -x 1

• %util > 80% → 磁盘接近饱和

• await远超svctm → 请求在排队，磁盘是瓶颈

• 如果磁盘是瓶颈，检查是读多还是写多——读多考虑加缓存，写多考虑换SSD

4. 网络

sar -n DEV 1

• 网络吞吐量接近带宽上限 → 升级带宽或减少跨节点数据传输

五、一个完整的排查案例

某系统在业务高峰期响应变慢，DBA翻慢查询日志，没发现特别慢的SQL。执行计划都正常，索引也都在用。

第一层排查：SQL层没问题。

第二层排查：连接数正常，锁等待正常，缓冲池命中率97%。

第三层排查：

top一看，us只有15%，wa高达35%——CPU在等磁盘。

iostat -x 1显示磁盘%util长期在90%以上，await超过80ms。

排查发现，系统在做每日全量备份，备份进程占用了大量磁盘I/O，导致数据库读写全部排队。

解决方案：把备份时间调整到业务低峰期，并使用增量备份代替全量备份。调整后，系统恢复正常。

六、分层诊断的决策树

系统变慢
    ↓
第一层：SQL层
    ↓
慢查询日志 → 找到慢SQL → EXPLAIN看执行计划
    ↓
有SQL问题？─── 是 → 改SQL/加索引 → 验证
    ↓ 否
第二层：数据库层
    ↓
连接数、锁等待、缓冲池命中率、临时表、参数
    ↓
有数据库问题？─── 是 → 调参数/扩内存/改配置 → 验证
    ↓ 否
第三层：操作系统层
    ↓
CPU、内存、磁盘I/O、网络
    ↓
有系统问题？─── 是 → 升级硬件/调整备份策略/扩容 → 验证
    ↓ 否
检查外部依赖（网络、应用服务器、第三方API）

七、总结

性能问题的排查，最忌讳的就是“跳步”——看到慢查询就死磕SQL，或者一上来就怀疑硬件不够。

分层诊断的核心逻辑是：从内到外、从软件到硬件、从低成本到高成本。

层级	排查内容	工具	解决成本
SQL层	SQL写法、索引、统计信息	慢查询日志、EXPLAIN	最低
数据库层	连接、锁、缓冲池、参数	INNODB_TRX、状态变量	中等
操作系统层	CPU、内存、磁盘、网络	top、iostat、vmstat	最高

先查SQL，再查数据库，最后查操作系统——每层都有明确的排查清单和工具。按照这个顺序走，90%的性能问题都能在30分钟内定位。

小耶在手，SQL 不愁

还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~