数据库变慢时，监控指标要从操作系统、数据库实例、查询语句和应用层四个维度分步排查，其中CPU使用率、IO等待时间、活跃连接数、慢查询数量和锁等待情况是最关键的五个数据点。
数据库变慢时，监控指标有哪些？从操作系统开始
无论你用的是MySQL、PostgreSQL还是Oracle，操作系统层面的指标永远是第一道防线，很多排查卡在数据库内部，却忽略了CPU、IO、内存和网络这四个基础件。
CPU使用率过高是数据库变慢的典型信号
用top或vmstat看一眼，如果us（用户态）长期超过80%，说明数据库进程自身在大量消耗CPU，常见场景是复杂SQL、高频并发或大量排序操作，如果sy（系统态）偏高，则可能是上下文切换频繁或内核锁竞争，在虚拟化环境中尤其常见。
该如何判断CPU瓶颈？ 进入数据库，用show processlist看一眼当前执行中的查询，如果一堆会话都在Sending data或Sorting result，基本可以确定是查询需要优化，如果Sleep状态很多但CPU仍然高，那就得检查连接池是否过度创建。
IO瓶颈：数据库最常见的卡顿元凶
磁盘IO往往是数据库变慢的深层原因,但大部分时间被误判为CPU问题，用iostat -x 1抓取数据，关注await（平均每次IO等待时间）和%util（磁盘使用率），await超过20ms说明磁盘响应已经吃力，%util接近100%则代表磁盘饱和。
区分读和写：读IO高通常意味着数据未命中缓存，比如MySQL的buffer pool命中率低于99%，索引缺失或扫描大量数据，写IO高则可能是频繁提交事务、redo log刷盘过密或binlog写压力大，场景：在统计报表时段，你会发现CPU不高但整个库响应变慢，iostat显示%util爆满，这时候优先考虑增加内存或优化写入策略。
内存与网络：容易被忽略的维度
内存不足会直接导致数据库使用swap,性能瞬间崩塌，使用free -h检测，如果swap used大于0，就需要排查是否buffer pool分配过大或操作系统内存不足，对于MySQL，Innodb_buffer_pool_read_requests 和 Innodb_buffer_pool_reads的比值可以反映命中率，命中率低于99%是危险信号。
网络方面,分布式数据库或远程连接场景下，
TCP重传率是重要指标，用netstat -s看retransmitted segments占比，如果超过1%，说明网络链路不稳定，会造成大量行级传输超时，客户端感知到的延迟就会飙升。
生产环境数据库监控，这三大维度必须看
操作系统层面解决后,第二步是深入数据库实例内部，行业共识认为，连接数、资源瓶颈类型和锁等待是生产环境中最容易出问题的三个点。
数据库连接数过高怎么排查？场景化操作步骤
连接数满导致新请求排队,是数据库变慢最容易被忽视的假象之一。操作步骤：先用show variables like 'max_connections'查看最大连接数，再用show processlist或select count() from information_schema.processlist统计当前连接数，如果已接近阈值，说明需要紧急扩容或清理空闲连接。
场景化排查：在电商大促页面，你会发现数据库连接数瞬间飙满，但show processlist里大部分是Sleep状态，这往往是因为应用层连接池没有合理设置超时释放，或是连接泄漏，此时只需要杀掉空闲连接或重启应用池，就能快速恢复，如果大量Active连接且长期不释放，则说明有慢查询在阻塞，需要结合慢日志定位。
是CPU瓶颈还是IO瓶颈？对比分析两个维度
很多运维人员遇到变慢会直接认为是CPU不够,但实际场景中IO瓶颈的发生率更高。如何对比分析？ 同时打开top和iostat，观察CPU使用率与磁盘IO等待率的对应关系。
- CPU高但IO低：说明数据库在大量计算，比如复杂的聚合查询、缺少索引导致的扫描、或者大量排序，此时需要从查询入手，分析执行计划。
- CPU低但IO高：说明磁盘成为短板，数据读取或写入等待时间过长，常见于数据量暴增或缓存命中率下降，需要增加内存或优化IO路径。
- CPU和IO都高：可能是并发高且大量数据操作，需要评估拆分查询或增加读写分离节点。
一句话经验：业务高峰期CPU高IO低，通常是查询优化问题；业务低峰期IO高CPU低，往往是批处理任务或备份导致的IO争抢。
锁等待与死锁：数据库变慢的隐形杀手
当连接数和CPU都正常,但特定查询总是卡住，大概率是锁在作祟，锁等待会导致即使CPU空闲，事务也无法推进，用
show engine innodb status查看当前锁等待信息，重点关注LATEST DETECTED DEADLOCK和TRANSACTIONS部分。
场景：一个更新操作频繁的订单表，多个事务同时修改同一行，就会产生行级锁等待，如果锁等待超时，应用会重试，重试次数多了，整体响应就会变慢，死锁虽然会自动回滚，但频繁死锁说明业务逻辑存在交叉访问，需要调整事务顺序。建议：监控Innodb_row_lock_current_waits和Innodb_deadlocks计数器，一旦出现持续增长，必须立刻处理。
数据库慢查询如何定位？一条SQL拖垮整个库
慢查询是数据库变慢最直接的可视化证据,业内专家指出，约七八成的数据库性能问题都能从慢查询日志中找到根源。
慢查询日志开启与分析
生产环境建议开启慢查询日志,并设置阈值long_query_time=1秒，用set global slow_query_log=on开启，然后定期分析。命令：mysqldumpslow -s t -t 10 /var/log/mysql/slow.log可以按时间排序取出最慢的10条SQL。
实操步骤：
- 找到慢查询日志文件。
- 使用
pt-query-digest工具汇总，它会按查询指纹归类，告诉你哪些SQL消耗了最多的时间或资源。 - 针对排名靠前的查询,执行
explain分析执行计划，重点关注type（是否全表扫描）、rows（扫描行数）和Extra（是否使用临时表、文件排序）。
索引使用情况监控
慢查询的常见原因是没有有效利用索引,用show index from table_name检查索引是否合理，对于频繁出现在where和join条件的字段，应该建立索引，但要注意，索引不是越多越好，维护索引本身也会消耗资源。
判断索引是否被使用：在慢查询日志中，如果看到Using filesort或Using temporary，说明查询需要优化索引或调整SQL写法，场景：一个统计报表查询，每天凌晨都要跑10分钟，用explain发现是ALL全表扫描，加了一个复合索引后，耗时降到0.5秒。
数据库变慢的根源有时候不在数据库本身
当你把上述四个维度都查了一遍,却发现数据库内部负载很低，那么问题很可能出在应用层或硬件层。
应用层连接池配置不当：连接池大小太小，会导致请求排队等待连接，此时数据库的活跃连接数不高，但客户端响应很慢，检查hikariCP或Druid的连接池配置，maximumPoolSize应该根据业务并发合理设置，通常建议不超过CPU核心数的两倍。
缓存失效造成大量回源：应用层缓存（如Redis）一旦大面积失效，所有请求会同时打到数据库，你会发现数据库的查询量瞬间飙升，但单条查询本身并不慢，这时候需要检查缓存命中率，或者考虑缓存预热策略。
硬件故障：磁盘坏道、内存错误、网卡丢包，这些硬件问题也会引起数据库莫名变慢，用dmesg查看系统日志，如果出现I/O error或memory error，需要更换硬件。
数据库变慢时监控指标，常见问题与解答
数据库变慢时，监控指标还有哪些常被忽略？
除了常规的CPU、IO、连接数，redo log生成速率和临时表创建频率也是值得关注的指标，redo log生成过快意味着写入压力大，临时表创建频繁则说明SQL优化不够，据统计，在相当一部分数据库变慢案例中，这些指标比CPU更早报警。
数据库CPU飙升100%怎么处理？
首先用top确认是数据库进程占用CPU，然后进入数据库，执行show processlist找到当前正在运行的SQL，通常会有几个查询在长时间执行，用kill命令终止这些会话，再通过explain分析具体SQL的执行计划，优化索引或改写查询，如果CPU飙升是统计信息更新或数据备份导致，则需要错开执行时间，注意，在无法立即优化时，先临时限流或迁移读流量。
数据库IO等待过高如何优化？
IO等待高时,先用iostat -x确认是读还是写，读等待高，检查innodb_buffer_pool_size是否偏小，适当增大缓存池可以显著降低物理读，写等待高，检查innodb_flush_log_at_trx_commit是否设置为1（每次提交刷盘），如果业务允许数据丢失，可以改为2来降低写IO压力，使用SSD替换机械硬盘，或者调整脏页刷新参数innodb_max_dirty_pages_pct，都能有效降低IO等待。