数据库服务器CPU满了，先别急着重启，核心动作是保留现场、分清慢SQL、连接风暴、锁等待还是后台任务，再按限流降级、索引优化、读写分离、扩容的顺序处理。
CPU打满只是结果,不是根因，数据库像一台持续运转的收银机，CPU是收银员的手速，手速突然拉满，可能是顾客暴增，也可能是每单结算流程太绕，下面按排查、区分、场景处置、扩容评估和落地顺序展开。
数据库服务器CPU占用100%怎么排查？先看这三类指标
系统层：先看CPU是用户态高还是内核态高
登录服务器后,先用命令抓现场，不要只看一个top就下结论。
top -Hp <数据库进程PID>：看哪个线程在吃CPU。pidstat -u -p <PID> 1：观察用户态和内核态占比。vmstat 1：看上下文切换、运行队列和阻塞进程。iostat -x 1：排除磁盘IO等待导致的CPU异常。sar -u 1 3：回看近期CPU波动。
用户态高,常见于慢查询、排序、函数计算、全表扫描，内核态高，常见于上下文切换频繁、网络包处理、锁争用，数据库进程如果伴随大量cs上下文切换，要优先怀疑连接风暴或锁自旋。
数据库层：活跃会话和等待事件比利用率更有用
MySQL可执行：
SHOW FULL PROCESSLIST;看当前会话和状态。SHOW ENGINE INNODB STATUS\G看锁等待和事务状态。SELECT FROM sys.session WHERE command <> 'Sleep';找活跃会话。SELECT FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 20;找高耗时SQL模板。SHOW GLOBAL STATUS LIKE 'Threads_connected';看连接数。SHOW GLOBAL STATUS LIKE 'Slow_queries';看慢查询累计量。
PostgreSQL可查pg_stat_activity和pg_stat_statements，重点看活跃会话数、等待事件、单条SQL耗时，业内专家指出，CPU利用率只是结果指标，等待事件和慢查询才是根因线索。
业务层：分清QPS突增还是单条SQL拖垮
对比历史基线,看QPS、TPS、连接数、慢查询数、锁等待是否同步上升。
| 现象 | 优先排查 | 常见原因 | 处置方向 |
|---|---|---|---|
| CPU高，QPS也高 | 业务流量、连接池 | 活动流量、重试风暴 | 限流、降级、加只读 |
| CPU高，QPS正常 | 慢SQL、后台任务 | 全表扫描、排序、备份 | 优化SQL、错峰任务 |
| CPU高，连接数飙升 | 应用连接池 | 连接泄漏、重试放大 | 收敛连接、重启应用侧 |
| CPU高，IO也高 | 磁盘、临时表 | 大查询落盘、批量导入 | 拆批、加索引、错峰 |
MySQL数据库CPU高和内存高有什么区别？别只盯一个指标
CPU高更像“算得太忙”，内存高更像“装得太满”
CPU高通常指向计算和并发,内存高更多看缓冲池命中率、临时表、连接缓冲和内存泄漏，两者可能同时出现，但处置顺序不同。
- CPU高先查慢SQL、并发连接、锁等待、后台统计。
- 内存高先查Buffer Pool命中率、临时表落盘、连接内存占用。
- 两者都高时,先止血CPU，再评估内存是否被大查询拖累。
慢查询是头号嫌疑人，用三步抓出来
- 确认慢日志开启：
SHOW VARIABLES LIKE 'slow_query_log';、SHOW VARIABLES LIKE 'long_query_time';。 - 用
pt-query-digest分析慢日志，按总耗时排序，不要只看单次最慢。 - 对高频SQL执行
EXPLAIN，检查索引、扫描行数、临时表和文件排序。
常见优化动作包括：补联合索引、避免SELECT 、减少深分页、消除隐式类型转换、拆分大事务，索引不是越多越好，写多读少的表要控制索引数量。
连接风暴和锁等待也会把CPU打满
应用重试放大时,数据库会收到成倍连接，先看连接池最大连接数、空闲连接回收、超时设置，MySQL可查information_schema.innodb_trx和performance_schema.data_locks找长事务和锁等待，处理长事务前先确认业务影响，不能直接批量杀会话。
备份、统计、DDL等后台任务别忘了看
批量导入、备份压缩、定时统计、在线DDL都可能短时拉高CPU，检查crontab -l、事件调度器、备份窗口和DDL执行记录，把重任务挪到低峰期，并设置资源限制。
电商大促期间数据库CPU飙高怎么处理？场景化处置清单
先止损：限流、降级、读写分离
大促场景下,先保证核心链路，应用层对非核心查询限流，关闭排行榜、推荐位等重查询，商品详情和库存走缓存，读请求切到只读实例，写请求保持主库，连接池要设置排队上限，避免重试风暴继续压库。
再定位：按业务链路找热点
从订单、库存、商品、支付四条链路分别看QPS和慢SQL，热点商品可能引发缓存击穿，库存扣减可能引发行锁竞争，把慢SQL按业务接口归因，比只看数据库指标更快。
后复盘：容量评估和预案要提前做
大促前做压测,评审新增SQL，配置慢查询和连接数告警，准备只读实例切换预案、缓存预热清单和降级开关，行业共识认为，数据库性能突发问题里，慢SQL与连接风暴往往占较大比例。
云数据库CPU扩容价格怎么算？先做容量评估再谈钱
扩容不是第一反应，先判断缺资源还是用错资源
如果CPU高由慢SQL引起,升配只是把问题推迟，先看CPU高位是否持续、QPS是否正常、慢查询是否集中，长期高位且业务量真实增长，再考虑升配或加只读实例。
云数据库CPU扩容价格受哪些因素影响
价格通常和实例规格、存储类型、地域、计费方式、只读实例数量有关，包年包月和按量计费差异较大，不同地域报价也可能不同，实操路径是：打开云厂商价格页，用成本计算器对比“升配主实例”和“增加只读实例”的月度成本，再结合压测结果决策。
| 扩容方式 | 适用场景 | 成本特点 | 注意点 |
|---|---|---|---|
| 升配主实例 | CPU长期高位、写入也重 | 单价上升明显 | 变更窗口和连接闪断 |
| 增加只读实例 | 读多写少、报表查询多 | 按实例叠加 | 延迟和读一致性 |
| 缓存前置 | 热点查询重复度高 | 需应用改造 | 缓存击穿和雪崩 |
| 分库分表 | 数据量和写入持续增长 | 改造周期长 | 事务和路由复杂度 |
在北京、上海等IDC托管场景，远程处置还要确认带外管理口、KVM权限和变更审批，云上实例则先看云监控历史曲线，再提交工单确认升配影响。
一套可落地的处置顺序：先止血，再定位，后治理
5分钟止血清单
- 暂停非核心批量任务和报表查询。
- 对应用侧接口限流,关闭重试放大。
- 检查连接数,回收异常空闲连接。
- 读请求切只读实例或缓存。
- 保留
top、慢日志、活跃会话现场。
30分钟定位清单
- 用
top -Hp找高CPU线程。 - 用
SHOW FULL PROCESSLIST找活跃SQL。 - 用慢日志和
EXPLAIN确认执行计划。 - 查锁等待、长事务、备份和统计任务。
- 对比QPS、连接数、慢查询历史基线。
长期治理清单
- 建立SQL审核和索引评审。
- 配置CPU、连接数、慢查询、锁等待告警。
- 大促前压测,准备降级开关。
- 定期清理低效索引和无用连接。
- 把备份、统计、DDL放到低峰窗口。
数据库服务器CPU满了：常见问题解答
数据库服务器CPU满了能不能直接重启？
不建议直接重启,重启会丢失现场，连接风暴和慢SQL可能很快复现，先保留会话、慢日志和监控曲线，再决定限流、杀会话或切换只读实例，必须重启时，先确认主从切换和备份可用。
数据库服务器CPU占用高但业务不慢，需要处理吗？
需要看持续时间和趋势,短时高CPU可能来自备份、统计或批量任务，错峰即可，持续高位且连接数、慢查询同步上升，说明余量不足，应做容量评估，业务不慢不代表没有风险，故障往往在流量再涨一点时出现。
云数据库CPU满了，升配和加只读实例选哪个？
读多写少、慢查询集中在报表和列表页，优先加只读实例并做读写分离，写入也重、CPU长期高位，才考虑升配主实例，扩容前先用慢日志和压测确认瓶颈，否则升配后慢SQL仍会继续消耗CPU。
数据库服务器CPU满了，处理顺序比工具更重要：先保留现场，再分清慢SQL、连接风暴、锁等待和后台任务，最后才谈扩容，把限流降级、SQL优化和容量评估做成常态，CPU告警才不会每次都变成救火。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/786054.html
