遇到数据库CPU或IO飙升，排查的核心思路其实就是一场侦探游戏，我们要做的就是顺藤摸瓜，找到那个在背后大肆消耗资源的“罪魁祸首”。通常，这指向了几个关键点：是否有异常的慢查询在执行，索引是否得当，抑或是系统层面或应用层面的并发瓶颈。快速定位并分析这些问题，是解决此类性能危机的关键。
解决方案解决数据库CPU或IO飙升，我通常会遵循一个由表及里、从宏观到微观的排查路径。
首先，我会迅速查看系统的整体资源使用情况。在Linux环境下，
top命令是我的老朋友，它能告诉我CPU、内存的实时占用，以及哪些进程消耗最多。如果看到数据库进程（比如
mysqld或
postgres）CPU占用居高不下，那基本就锁定方向了。同时，
iostat -x 1或
vmstat 1也能提供宝贵的IO数据，比如磁盘读写速度、等待队列长度等，直观反映IO是否是瓶颈。
接着，我会深入到数据库内部。对于MySQL，
SHOW PROCESSLIST是我的第一选择，它能列出所有正在执行的查询，哪个查询运行了多久，状态是什么。我特别关注那些
State为
Running且
Time很长的查询，或者那些看起来正在进行大量计算的查询。PostgreSQL则有
pg_stat_activity视图，提供类似的信息。通过这些，我能大致判断是不是有某个特定的SQL语句导致了问题。
一旦定位到可疑的SQL，下一步就是分析它的执行计划。
EXPLAIN ANALYZE（PostgreSQL）或
EXPLAIN（MySQL）能详细展示查询是如何被数据库执行的，它走了哪些索引，是否进行了全表扫描，是否创建了临时表等等。这往往能揭示出索引缺失、索引失效或查询语句本身效率低下的问题。很多时候，一个看似简单的
SELECT语句，在数据量庞大时，没有合适的索引就会变成性能杀手。
如果排除了慢查询和索引问题，我会考虑并发。是不是有大量的连接同时涌入，导致数据库连接池耗尽，或者产生了大量的锁等待？这在应用发布或流量高峰时特别常见。通过查看数据库的连接数、锁信息（如MySQL的
SHOW ENGINE INNODB STATUS或PostgreSQL的
pg_locks），可以进一步确认。
最后，别忘了硬件和配置。数据库配置参数是否合理？比如内存分配、缓存大小等。磁盘I/O性能是否达到瓶颈？这些底层因素有时才是真正的症结所在。
如何快速定位导致数据库CPU飙升的SQL查询？快速定位导致数据库CPU飙升的SQL查询，我的经验是，要善用数据库自带的性能监控工具，并结合操作系统层面的观察。
通常，我会先用
top命令确认
mysqld或
postgres进程确实是CPU的“大户”。确认之后，直接进入数据库内部。
对于MySQL，我会立刻执行
SHOW PROCESSLIST。这个命令会列出当前所有正在执行的SQL语句。我会特别留意
Time列，那些运行时间过长的语句是重点怀疑对象。同时，
State列也很关键，例如
Sending data、
Sorting result、
Copying to tmp table等状态，都暗示着该查询可能正在进行大量计算或IO操作。如果
State是
Locked，那说明它可能在等待某个锁，这也会间接导致其他查询等待，从而加剧CPU压力。
如果
SHOW PROCESSLIST刷新的太快，或者想要更详细的历史数据，MySQL的 Performance Schema 和 Slow Query Log 是不可或缺的。开启慢查询日志，并设置一个合理的
long_query_time，所有超过这个时间的查询都会被记录下来。分析慢查询日志工具（如
pt-query-digest）能帮你快速汇总和分析出最耗时的查询。Performance Schema则提供了更细粒度的监控，可以查询到消耗CPU最多的事件、语句等。
PostgreSQL这边，
SELECT * FROM pg_stat_activity WHERE state = 'active' ORDER BY query_start;是我的常用指令。它能展示当前活跃的会话和它们正在执行的查询。我也会关注
waiting字段，如果为
true，说明查询正在等待锁，这同样是CPU飙升的间接原因。PostgreSQL的 pg_stat_statements 扩展也异常强大，它能跟踪所有执行过的SQL语句的统计信息，包括执行次数、总耗时、平均耗时等，这对于找出高频且耗时的查询非常有帮助。
定位到可疑查询后，下一步就是
EXPLAIN ANALYZE。这个命令会实际执行查询并返回执行计划和统计信息，比如扫描了多少行、耗时多少、是否使用了索引等。通过分析执行计划，我们能判断查询是否高效，是否可以优化索引，或者重写查询逻辑。我记得有一次，一个简单的
COUNT(*)操作导致了数据库CPU飙升，
EXPLAIN后才发现，由于WHERE条件不走索引，数据库被迫进行了全表扫描，数据量一上去，CPU就爆了。 数据库IO飙升时，应该从哪些维度进行深入分析？
数据库IO飙升，通常意味着磁盘成为了瓶颈，数据读写跟不上节奏。遇到这种情况，我通常会从几个维度进行深入分析。
PIA
全面的AI聚合平台，一站式访问所有顶级AI模型
226
查看详情
首先，操作系统层面的IO监控是必不可少的。
iostat -x 1或
sar -d 1能够提供磁盘的详细IO统计，比如
r/s(每秒读请求数),
w/s(每秒写请求数),
rKB/s(每秒读KB数),
wKB/s(每秒写KB数),
await(IO请求平均等待时间),
%util(磁盘利用率)。如果
%util接近100%且
await时间很长，那基本可以确定IO是瓶颈。同时，
vmstat 1也能观察到
bi(blocks in) 和
bo(blocks out)，反映了块设备的读写情况。
接着，我会深入到数据库内部，寻找导致大量IO的“罪魁祸首”。 1. 慢查询与全表扫描： 这是最常见的IO杀手。如果查询没有命中索引，或者索引选择性很差，数据库就不得不进行大量的全表扫描或索引扫描，从而产生大量的磁盘读。通过前面提到的
SHOW PROCESSLIST、慢查询日志或
pg_stat_activity找出这些查询，然后用
EXPLAIN ANALYZE分析其执行计划，确认是否进行了不必要的全表扫描或大范围索引扫描。很多时候，一个
ORDER BY或
GROUP BY操作，如果数据量大且没有合适索引，也会导致创建临时表，这些临时表如果太大，就不得不写入磁盘，造成大量IO。
2. 写入密集型操作： 如果数据库主要是写操作导致IO飙升，那可能是大量的数据插入、更新或删除操作。例如，批量导入数据、日志表的高并发写入、或者复杂的事务操作导致的大量redo/undo日志写入。这时需要检查应用程序的写入模式，是否可以优化为批量写入，或者调整事务粒度。
3. 索引重建或维护： 数据库管理员在进行索引重建、表优化（如
OPTIMIZE TABLE）或大表结构变更时，也会产生大量的IO。这些操作通常是计划内的，但如果是在高峰期执行，就可能导致IO飙升。
4. 数据库缓存命中率： 检查数据库的缓存（如MySQL的
InnoDB Buffer Pool，PostgreSQL的
shared_buffers）命中率。如果命中率很低，说明大部分数据请求都需要从磁盘读取，这必然导致IO飙升。优化缓存大小、调整查询使其更有效利用缓存是解决之道。
5. 存储系统本身的问题： 排除数据库层面的问题后，有时IO瓶颈是由于底层存储系统本身性能不足导致的。比如，使用了低速的HDD而非SSD，RAID配置不合理，或者存储网络（SAN/NAS）存在拥堵。这时，就需要与系统管理员或存储团队协作，检查硬件配置和存储性能。我曾遇到过一次，数据库IO居高不下，最后发现是存储阵列某个磁盘故障导致性能下降，或者存储网络链路拥堵。
除了慢查询和IO，还有哪些不常见的因素可能导致数据库性能瓶颈？确实，数据库性能瓶颈并非总是慢查询或IO飙升那么直接。在我的职业生涯中，也遇到过一些不那么显眼，但同样致命的“隐形杀手”。
1. 锁竞争（Lock Contention）： 这玩意儿可真是个“隐形杀手”。当多个事务尝试访问或修改同一行、同一页甚至同一张表时，就会产生锁。如果某个事务持有锁的时间过长，其他等待该锁的事务就会被阻塞，导致整个系统的吞吐量急剧下降，CPU可能看起来不高，但响应时间却很长。死锁更是其中的极端情况。排查这类问题，我通常会查看数据库的锁信息（如MySQL的
SHOW ENGINE INNODB STATUS中的
LATEST DETECTED DEADLOCK部分，或PostgreSQL的
pg_locks视图），分析哪些事务持有锁，哪些事务在等待，以及它们的持续时间。优化事务逻辑，减小事务粒度，或者调整隔离级别，都有助于缓解锁竞争。
2. 连接风暴与连接池耗尽： 应用程序在短时间内创建大量数据库连接，或者连接池配置不当，都会导致数据库连接数迅速达到上限。这不仅会耗尽数据库资源（每个连接都需要一定的内存和CPU），还会导致新的连接请求被拒绝或长时间等待，最终表现为应用响应缓慢甚至不可用。数据库的
max_connections参数设置不合理，或者应用层没有正确使用连接池，都可能引发此类问题。我曾遇到一个案例，某个微服务在启动时没有正确初始化连接池，导致瞬间创建了数百个连接，直接把数据库打垮了。
3. 统计信息过时或缺失： 数据库的查询优化器依赖于表的统计信息来生成最优的执行计划。如果统计信息过时（例如，表数据发生了大量增删改，但没有及时
ANALYZE TABLE或
VACUUM ANALYZE），优化器就可能做出错误的判断，选择一个效率低下的执行计划，比如原本应该走索引的查询却走了全表扫描，间接导致CPU或IO飙升。这是一种很隐蔽的问题，因为SQL本身看起来没问题，索引也存在。
4. 内存不足导致的频繁交换（Swapping）： 虽然这不是数据库内部问题，但操作系统层面如果内存不足，导致系统频繁地将内存中的数据交换到磁盘上（Swap），这会产生大量的磁盘IO，严重拖慢整个系统的性能，包括数据库。这时，
vmstat命令的
si(swap in) 和
so(swap out) 列会显示非零值。解决办法通常是增加物理内存，或者优化数据库和应用的内存使用。
5. 复制延迟（Replication Lag）： 在主从复制架构中，如果从库因为某些原因（如IO性能差、网络延迟、大事务）无法及时应用主库的更新日志，就会产生复制延迟。这不仅影响数据一致性，还可能导致从库上的查询无法获取最新数据，甚至在某些情况下，如果应用依赖从库提供读服务，延迟过高会直接影响用户体验。排查时需要查看复制状态（如MySQL的
SHOW SLAVE STATUS或PostgreSQL的
pg_stat_replication）。
6. 应用程序的N+1查询问题： 这通常发生在ORM框架中，为了获取一个列表的数据以及每个列表项的关联数据，应用程序会先执行一个查询获取列表，然后对列表中的每个项再执行一个单独的查询。如果列表有N个项，就会执行N+1个查询，导致数据库连接和查询次数激增，尽管单个查询可能很快，但累积起来就成了性能瓶颈。优化方法通常是使用JOIN或预加载（eager loading）来减少查询次数。
以上就是遇到过数据库CPU或IO飙升的情况吗？如何排查？的详细内容，更多请关注知识资源分享宝库其它相关文章！
相关标签： mysql linux 操作系统 app 工具 ssl ai ios sql语句 red 有锁 sql mysql 架构 count select 并发 对象 事件 table postgresql 数据库 linux 大家都在看： MySQL内存使用过高（OOM）的诊断与优化配置 MySQL与NoSQL的融合：探索MySQL Document Store的应用 如何通过canal等工具实现MySQL到其他数据源的实时同步？ 使用Debezium进行MySQL变更数据捕获（CDC）实战 如何设计和优化MySQL中的大表分页查询方案
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。