大家好我是小耶写功课只是为了我踩过的坑你们别再踩了上周讲了参数调优——哪些参数值得调、怎么调。但有一个前置问题没解决你怎么知道该调哪个参数系统慢了CPU飙了磁盘I/O满了内存快爆了——面对一堆异常指标先查哪个很多DBA的直觉是“CPU最高就先看CPU”。但CPU高往往是表象真正的根因可能在磁盘、在网络、在内存。今天不讲具体参数先讲一套诊断优先级——遇到性能问题按什么顺序排查才不会走弯路。一、先系统后数据库不要一上来就查SQL接到“系统慢了”的反馈很多DBA的第一反应是翻慢查询日志。这个直觉可以理解但往往是低效的。正确的排查顺序是先看系统层再看数据库层。系统层是“体检”——CPU、内存、IO、网络四大资源哪个亮了红灯数据库层是“问诊”——系统层没有瓶颈时才深入数据库内部排查系统层已亮红灯时优先解决资源问题。慢查询日志只记录了“已经慢了的SQL”不记录“为什么慢”。如果系统层资源已经打满了翻慢查询日志是浪费时间——先把资源问题解决了慢查询自然就少了。二、四大资源的诊断优先级遇到性能问题建议按以下顺序排查第一步查磁盘I/O优先级最高为什么I/O排第一因为I/O问题是数据库性能问题最常见的根源。而且I/O问题的特征很明确容易被误判为CPU问题。怎么看# 实时查看磁盘I/O iostat -x 1关键指标指标含义危险信号%util磁盘繁忙程度80% 说明磁盘快打满了awaitI/O请求平均等待时间远超svctm说明在排队r/s/w/s每秒读写次数接近磁盘IOPS上限watop中CPU等待I/O的时间10%说明I/O是瓶颈CPU在空等磁盘常见场景top里看到CPU使用率很高但waiowait也很高——CPU其实在等磁盘不是在算数据。这时候加CPU没用得解决磁盘问题。怎么解决检查是否有全表扫描会在第三步确认检查是否有大量排序操作或临时表写磁盘调整innodb_io_capacity等I/O相关参数考虑升级磁盘HDD→SSD→NVMe第二步查内存优先级第二内存不足会导致频繁的磁盘交换Swap而Swap一发生性能会直接崩盘。内存问题往往表现为“磁盘I/O高”或“CPU高”——因为内存不够系统在频繁换页CPU忙着处理换页中断。怎么看# 查看内存使用 free -h # 查看是否有Swap活动 vmstat 1关键指标指标含义危险信号available/free可用内存接近0说明内存不足si/sovmstatSwap换入/换出非0说明内存在换页InnoDB缓冲池命中率数据页在内存中的命中比例95%说明缓冲池不够大常见场景free -h显示内存快用完了vmstat的si和so列出现非0值。这时候查SQL没用——加内存才是正解。怎么解决调整innodb_buffer_pool_size通常设为物理内存的50%-70%检查是否有内存泄露连接未释放、大查询占用大量临时内存考虑增加物理内存第三步查CPU优先级第三CPU高是数据库性能问题最常见的“报警信号”但它往往是结果不是原因。所以CPU排在第三位——先排除了I/O和内存的问题再看CPU。怎么看# 查看CPU使用情况 top关键指标指标含义危险信号us用户态应用在跑计算高说明SQL在做大量计算或排序sy内核态系统在忙高说明连接风暴或锁竞争waI/O等待CPU在等磁盘高说明磁盘是瓶颈load average系统平均负载持续高于CPU核数说明过载us高的场景us用户态CPU高说明SQL在做大量计算或排序。这时候才轮到查慢查询日志、看执行计划、优化SQL。sy高的场景sy内核态CPU高说明系统在频繁切换上下文。通常是连接风暴或大量锁竞争导致的。怎么解决us高 → 优化SQL、加索引、减少排序sy高 → 检查连接数是否突增、检查锁等待负载高 → 考虑升级CPU或增加节点第四步查网络优先级第四网络问题在集中式数据库中相对少见但在分布式架构中非常关键。网络瓶颈表现为高延迟和数据包丢失。怎么看# 查看网络流量 sar -n DEV 1关键指标指标含义危险信号网络吞吐量发送/接收速率接近带宽上限重传率数据包重传比例过高说明网络不稳定常见场景应用和数据库在不同机房跨区域调用延迟高或者云环境网络带宽被打满。怎么解决将应用和数据库部署在同一可用区升级网络带宽优化跨节点查询减少数据传输量三、诊断流程图接到“系统慢了”的反馈 ↓ 第一步看磁盘I/Oiostat -x 1 ↓ %util80% 或 wa10% ↓ 是 ↓ 否 解决磁盘问题 第二步看内存free -h ↓ ↓ 内存不足 或 Swap活动 ↓ 是 ↓ 否 解决内存问题 第三步看CPUtop ↓ us高 sy高 负载高 ↓ 查慢查询SQL、执行计划 ↓ 第四步看网络如有需要四、一个真实案例某电商系统在促销期间突然响应变慢DBA看到top里CPU使用率85%第一反应是“CPU瓶颈要加核”。但仔细看top的输出waiowait占了30%。这意味着CPU有30%的时间在“等磁盘”不是在“算数据”。用iostat -x 1一看磁盘%util长期在95%以上await超过50ms。根因是某张表的统计信息过旧导致优化器选错了执行计划频繁触发全表扫描把磁盘打满了。解决方案执行ANALYZE TABLE更新统计信息查询走了正确的索引磁盘I/O从95%降到30%CPU使用率从85%降到40%。系统恢复正常。复盘如果只看CPU高就去加核问题根本解决不了——加再多核CPU还是在等磁盘。五、总结遇到性能问题不要一上来就翻慢查询日志。先按这个顺序排查1. 磁盘I/O—— 最常见、最容易被误判的瓶颈。先看iostat和wa解决了I/O问题很多“CPU高”问题自然消失。2. 内存—— 内存不足导致Swap性能直接崩盘。先看free -h和vmstat。3. CPU—— 排除了I/O和内存再看CPU。us高查SQLsy高查连接和锁wa高回到第一步。4. 网络—— 分布式架构中不可忽视集中式架构中优先级最低。记住一句话先系统后数据库先资源后SQL。系统层亮了红灯就别在数据库层浪费时间。小耶在手SQL 不愁还有什么想了解的欢迎留言小耶一定知无不言言无不尽……我们下次见~