show processlist能查看state、time、info三列关键信息：state为sending data或copying to tmp table说明高负载，time超5秒需警惕，info中含order by、like '%xxx'等提示高开销。
show processlist 能看到什么关键信息
执行 show processlist 是定位高 CPU 查询的第一步，不是为了“看看”，而是盯住三列： state、time、info。如果 state 长时间停留在 Sending data 或 Copying to tmp table，说明查询正在大量处理数据或被迫建临时表；time 值大于 5 秒就该警惕；info 列哪怕被截断，也能看出是否含 ORDER BY、LIMIT、模糊匹配（LIKE '%xxx'）等高开销模式。
EXPLAIN 显示 type=ALL 就等于没走索引
EXPLAIN 输出中 type 字段是核心判断依据：ALL 表示全表扫描，index 是全索引扫描，这两种都意味着 MySQL 在逐行比对，CPU 必然拉满。常见诱因包括：
- WHERE 条件里对字段用了函数，比如
WHERE DATE(create_time) = '2026-08-11'—— 索引失效 - 联合索引顺序不匹配，例如索引是
(a,b,c)，但查询只用了WHERE c = ? - 字符串字段用
LIKE开头通配，如LIKE '%abc'，无法利用 B+ 树索引 - 隐式类型转换，比如
user_id是 bigint，但 SQL 中写成WHERE user_id = '123'
修复不是“加个索引”就行，得看 EXPLAIN 的 key 和 possible_keys 是否一致，rows 是否显著下降。
慢查询日志里藏着真实负载来源
别只依赖 long_query_time 设为 1 秒来抓“慢”SQL——CPU 高时，大量 0.3 秒的查询叠加起来一样压垮 CPU。正确做法是开启并实时采集慢日志，然后查 mysql.slow_log 表（需启用 log_output='TABLE'），按 query_time + lock_time + rows_examined 综合排序。特别注意那些 rows_examined 远大于返回行数的查询，比如 SELECT * FROM order WHERE status=1 LIMIT 10 却扫描了 50 万行，这就是典型的索引缺失或条件未覆盖。
kill 并不解决根本问题，但能立刻止血
发现某个 id 对应的线程持续占用 CPU，用 KILL [id] 是最快缓解手段。但要注意两点：
- 别在业务高峰直接 kill 主库写线程，尤其是涉及大事务的
UPDATE或DELETE，可能引发主从延迟或锁等待扩散 - kill 后必须立刻检查该 SQL 是否被应用层重试——循环重试会把问题放大，日志里出现同一语句反复出现，就得改代码加熔断或退避
- 临时降低负载后，要回溯到应用端确认调用频次，比如一个接口每秒触发 200 次相同查询，再好的索引也扛不住
真正难的从来不是找到那条慢 SQL，而是确认它为什么会被高频、高并发地执行——这往往卡在业务逻辑和数据访问层的设计里，而不是数据库配置上。
