大家好我是小耶写功课只是为了我踩过的坑你们别再踩了一条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、ExtraEXPLAIN FORMATJSON看成本估算cost_info中的read_cost、prefix_costOPTIMIZER_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-4GBinnodb_flush_log_at_trx_commit是否符合业务要求如果第二层排查完没问题进入第三层。四、第三层操作系统层——被忽略的“隐形瓶颈”SQL没问题数据库配置也没问题——但系统还是慢。这时候问题可能在操作系统。第三层排查清单1. CPUus高70%→ 应用在大量计算需要优化SQL或升级CPUsy高30%→ 系统在频繁切换上下文可能是连接风暴或锁竞争wa高10%→ CPU在等磁盘问题在I/O不是CPU2. 内存free -h vmstat 1available接近0 → 内存不足si/so非0 → 发生了Swap性能会急剧下降3. 磁盘I/Oiostat -x 1%util 80% → 磁盘接近饱和await远超svctm→ 请求在排队磁盘是瓶颈如果磁盘是瓶颈检查是读多还是写多——读多考虑加缓存写多考虑换SSD4. 网络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 不愁还有什么想了解的欢迎留言小耶一定知无不言言无不尽……我们下次见~