说实话，这大概是每一位后端开发或者DBAZui不想在凌晨三点接到的

今天咱们不聊那些虚头巴脑的理论，直接来点“硬菜”。我想结合自己这些年踩过的坑，还有那些在深夜里流过的汗，跟大家好好掰扯掰扯：当线上出现慢SQL导致CPU飙升时我们到底该怎么从排查、分析到优化，一步步把系统从悬崖边拉回来。

当你发现数据库CPU占用率Yi经超过80%甚至90%，并且应用端的响应时间开始大幅飙升时首要任务不是立刻去分析代码逻辑，而是要止损。这就好比病人大出血，医生得先止血，再谈治病。

你得登录到数据库服务器上。别一上来就扎进MySQL里先用 top 或者 htop 命令kan一眼。Ru果发现 mysqld 进程的CPU占用率居高不下那基本Ke以确定是数据库内部出了问题。这时候，Ru果服务器上还跑着其他服务，比如Java应用，也要顺便kan下是不是它们在抢资源，但通常情况下这种飙升dou是数据库自己在“内耗”。

进入MySQL命令行后第一件事就是执行 SHOW PROCESSLIST;。这条命令Neng让你kan到当前数据库里所有的线程状态。这时候你的眼睛要像雷达一样，重点扫描两个列：Time和 State。

Ru果你kan到大量的会话处于 Sending dataCopying to tmp table 或者 Sorting result 这种状态，而且执行时间长得离谱，那恭喜你，你找到罪魁祸首了。这些状态通常意味着数据库正在进行大量的磁盘扫描、排序或者创建临时表，这些dou是CPU和IO的杀手。

找到了消耗资源的线程ID，别犹豫，直接 KILL ;。我知道这听起来hen粗暴，但在系统Yi经濒临崩溃、其他正常请求dou排不上队的时候，牺牲掉这一小部分异常请求，保全整个集群的可用性，是必须Zuo出的取舍。当然Ru果你有运维脚本，Ke以设置个阈值，自动Kill掉那些执行时间超过N秒的SQL，这就属于自动化运维的范畴了。

当系统恢复平静，CPU降下来之后真正的战斗才刚刚开始。这时候，我们需要像侦探一样，去还原案发现场。为什么一条SQL会把CPU拖垮？

本质上，这是一个“数据库资源被低效查询耗尽”的问题。数据库的CPUdou在忙着Zuo逻辑读、排序、解析执行计划，根本没空处理正常的业务请求。这就好比一家餐厅，厨师dou在给一个难缠的客人切洋葱，导致其他点菜的客人饿肚子排队。

Ru果平时没开慢查询日志，那现在赶紧补上。执行 SET GLOBAL slow_query_log = 1;，并把阈值设低一点，比如 SET GLOBAL long_query_time = 1;。这样，所有执行超过1秒的SQLdou会被记录下来。事后我们Ke以用 mysqldumpslow 或者 pt-query-digest 这些工具去分析日志，找出那些出现频率高、执行时间长的“惯犯”。

拿到嫌疑SQL后在前面加上 EXPLAIN，kankan它到底是怎么执行的。这里有几个关键指标你得盯紧了：

type这列告诉你MySQL是怎么找数据的。Ru果是 ALL，那就惨了这是全表扫描，意味着它在几百万行数据里一行行找，CPU不飙才怪。我们希望kan到的是 rangeref 或者 eq_ref，这说明它用到了索引。

SELECT o.order_no, u.phone, p.name, o.amount
FROM orders o
LEFT JOIN users u ON o.user_id = u.id
LEFT JOIN products p ON o.product_id = p.id
WHERE o.status = 'PAID'
  AND o.create_time BETWEEN '2023-10-01' AND '2023-10-31'
ORDER BY o.amount DESC
LIMIT 1000;

ALTER TABLE orders ADD INDEX idx_status_time_amount ;