首先检查系统资源使用情况，通过top和iostat确认数据库进程的CPU与IO消耗；接着利用SHOW PROCESSLIST或pg_stat_activity定位长时间运行或高负载的SQL；结合慢查询日志、Performance Schema或pg_stat_statements分析高频或低效语句；使用EXPLAIN ANALYZE查看执行计划，排查全表扫描、索引失效等问题；进一步检查锁竞争、连接数、缓存命中率及事务设计；最后排查统计信息过期、内存交换、复制延迟和应用层N+1查询等隐性因素，综合操作系统与数据库指标逐步缩小问题范围，精准识别并解决根本原因。
遇到数据库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飙升，通常意味着磁盘成为了瓶颈，数据读写跟不上节奏。遇到这种情况，我通常会从几个维度进行深入分析。
首先，操作系统层面的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）来减少查询次数。
