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

上周讲了参数调优——哪些参数值得调、怎么调。但有一个前置问题没解决：

系统慢了，CPU飙了，磁盘I/O满了，内存快爆了——面对一堆异常指标，先查哪个？

很多DBA的直觉是“CPU最高就先看CPU”。但CPU高往往是表象，真正的根因可能在磁盘、在网络、在内存。

——遇到性能问题，按什么顺序排查，才不会走弯路。

一、先系统后数据库：不要一上来就查SQL

接到“系统慢了”的反馈，很多DBA的第一反应是翻慢查询日志。这个直觉可以理解，但往往是低效的。

正确的排查顺序是：先看系统层，再看数据库层

系统层是“体检”——CPU、内存、IO、网络四大资源，哪个亮了红灯？数据库层是“问诊”——系统层没有瓶颈时，才深入数据库内部排查；系统层已亮红灯时，优先解决资源问题。

慢查询日志只记录了“已经慢了的SQL”，不记录“为什么慢”。如果系统层资源已经打满了，翻慢查询日志是浪费时间——先把资源问题解决了，慢查询自然就少了。

遇到性能问题，建议按以下顺序排查：

第一步：查磁盘I/O（优先级最高）

I/O问题是数据库性能问题最常见的根源

。而且I/O问题的特征很明确，容易被误判为CPU问题。

（iowait）也很高——CPU其实在等磁盘，不是在算数据。这时候加CPU没用，得解决磁盘问题。

第二步：查内存（优先级第二）

内存不足会导致频繁的磁盘交换（Swap），而Swap一发生，性能会直接崩盘。内存问题往往表现为“磁盘I/O高”或“CPU高”——因为内存不够，系统在频繁换页，CPU忙着处理换页中断。

# 查看内存使用
free -h
# 查看是否有Swap活动
vmstat 1

列出现非0值。这时候查SQL没用——加内存才是正解。

CPU高是数据库性能问题最常见的“报警信号”，但它往往是结果，不是原因。所以CPU排在第三位——先排除了I/O和内存的问题，再看CPU。

：us（用户态CPU）高，说明SQL在做大量计算或排序。这时候才轮到查慢查询日志、看执行计划、优化SQL。

：sy（内核态CPU）高，说明系统在频繁切换上下文。通常是连接风暴或大量锁竞争导致的。

第四步：查网络（优先级第四）

网络问题在集中式数据库中相对少见，但在分布式架构中非常关键。网络瓶颈表现为高延迟和数据包丢失。

：应用和数据库在不同机房，跨区域调用延迟高；或者云环境网络带宽被打满。

接到“系统慢了”的反馈
        ↓
第一步：看磁盘I/O（iostat -x 1）
        ↓
   %util>80% 或 wa>10%？
        ↓ 是               ↓ 否
   解决磁盘问题     第二步：看内存（free -h）
        ↓                    ↓
                      内存不足 或 Swap活动？
                            ↓ 是       ↓ 否
                      解决内存问题  第三步：看CPU（top）
                                        ↓
                                   us高？ sy高？ 负载高？
                                        ↓
                                   查慢查询SQL、执行计划
                                        ↓
                                   第四步：看网络（如有需要）

某电商系统在促销期间突然响应变慢，DBA看到

里CPU使用率85%，第一反应是“CPU瓶颈，要加核”。

（iowait）占了30%。这意味着CPU有30%的时间在“等磁盘”，不是在“算数据”。

超过50ms。根因是某张表的统计信息过旧，导致优化器选错了执行计划，频繁触发全表扫描，把磁盘打满了。

更新统计信息，查询走了正确的索引，磁盘I/O从95%降到30%，CPU使用率从85%降到40%。系统恢复正常。

：如果只看CPU高就去加核，问题根本解决不了——加再多核，CPU还是在等磁盘。

遇到性能问题，不要一上来就翻慢查询日志。先按这个顺序排查：

 —— 最常见、最容易被误判的瓶颈。先看

，解决了I/O问题，很多“CPU高”问题自然消失。

 —— 内存不足导致Swap，性能直接崩盘。先看

 —— 排除了I/O和内存再看CPU。

 —— 分布式架构中不可忽视，集中式架构中优先级最低。

记住一句话：先系统后数据库，先资源后SQL。

 系统层亮了红灯，就别在数据库层浪费时间。

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

上周讲了参数调优——哪些参数值得调、怎么调。但有一个前置问题没解决：你怎么知道该调哪个参数？

性能瓶颈的“诊断优先级”：CPU、IO、内存、网络，先查哪个？

系统慢了，CPU飙了，磁盘I/O满了——面对一堆异常指标，先查哪个？很多DBA的直觉是“CPU最高就先看CPU”，但CPU高往往是表象，真正的根因可能在磁盘、在网络、在内存。本文从系统层诊断的“先系统后数据库”原则出发，给出CPU、IO、内存、网络四大资源的诊断优先级和排查方法，帮助读者在面对性能问题时不再“眉毛胡子一把抓”。

数据库

运维

职业发展

数据库性能问题排查优先级：先查磁盘I/O（iostat看%util和wa），再查内存（free-h看可用内存和Swap），然后排查CPU（top看us/sy），最后检查网络。遵循"先系统后数据库"原则，避免直接翻慢查询日志。典型案例显示CPU高可能是磁盘I/O瓶颈导致的假象。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

性能瓶颈的“诊断优先级”：CPU、IO、内存、网络，先查哪个？

性能瓶颈的“诊断优先级”：CPU、IO、内存、网络，先查哪个？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐