大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
一条SQL慢，可能有一百种原因。
SQL写法有问题、索引没建对、统计信息过旧、参数没调好、磁盘I/O满了、内存不够、网络抖动……每种原因对应的排查方法完全不同。
很多DBA的做法是“先查SQL”——翻慢查询日志、看执行计划、加索引。如果运气好，问题就在SQL层，解决了。如果运气不好，折腾半天发现是磁盘打满了，或者内存不够导致Swap——前面全白干。
今天讲一套“分层诊断”的思路：从SQL层→数据库层→操作系统层，逐层排查，不跳步、不瞎猜。
一、分层诊断的核心逻辑
性能问题的根因可能在任何一层。先查哪一层，决定了你要花多少时间找到答案。
分层诊断的逻辑是：
- 先从SQL层入手——这是最直观、最容易定位的层面。如果问题在SQL层，改SQL或加索引就能解决，成本最低。
- SQL层没问题，再看数据库层——参数配置、连接池、锁等待、缓冲池命中率。
- 数据库层也没问题，最后看操作系统层——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或升级CPUsy高（>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 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
