遇到过数据库CPU或IO飙升的情况吗？如何排查？-mysql教程-PHP中文网

首先检查系统资源使用情况，通过top和iostat确认数据库进程的CPU与IO消耗；接着利用SHOW PROCESSLIST或pg_stat_activity定位长时间运行或高负载的SQL；结合慢查询日志、Performance Schema或pg_stat_statements分析高频或低效语句；使用EXPLAIN ANALYZE查看执行计划，排查全表扫描、索引失效等问题；进一步检查锁竞争、连接数、缓存命中率及事务设计；最后排查统计信息过期、内存交换、复制延迟和应用层N+1查询等隐性因素，综合操作系统与数据库指标逐步缩小问题范围，精准识别并解决根本原因。

遇到过数据库cpu或io飙升的情况吗？如何排查？

遇到数据库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飙升，通常意味着磁盘成为了瓶颈，数据读写跟不上节奏。遇到这种情况，我通常会从几个维度进行深入分析。

简篇AI排版

AI排版工具，上传图文素材，秒出专业效果！

554

查看详情

首先，操作系统层面的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飙升的情况吗？如何排查？的详细内容，更多请关注php中文网其它相关文章！