type=ALL或rows极大即表明全表扫描，MySQL逐行读取整张表，是CPU飙升的直接信号；常见原因包括索引失效、隐式转换、函数操作、JOIN无有效索引及子查询重写失控等。
EXPLAIN里type=ALL或rows极大，基本就是全表扫描
看到EXPLAIN结果中type列是ALL，或者rows值远超实际返回行数（比如查10条却扫50万行），说明MySQL正在逐行读取整张表——这是CPU飙升最直接的信号。尤其在JOIN场景下，如果驱动表没走索引，被驱动表又没关联字段索引，就容易触发嵌套循环的暴力匹配，CPU瞬间拉满。
常见诱因包括：
-
ON或WHERE条件里对关联字段用了函数，比如ON UPPER(u.name) = UPPER(o.user_name) - 字段类型不一致导致隐式转换，例如
orders.user_id是BIGINT，但users.id传的是字符串'123'，MySQL会悄悄给后者加CONVERT()，每行都算一次 - 联合索引没按最左前缀使用，比如索引是
(status, user_id)，但查询只写了WHERE user_id = 123
JOIN后出现Using temporary + Using filesort，CPU在内存里硬扛排序
当EXPLAIN的Extra列同时出现Using temporary和Using filesort，说明MySQL不得不创建临时表并做文件排序——这不是IO瓶颈，而是纯CPU密集型操作。特别是ORDER BY或GROUP BY字段没包含在索引里，或排序方向不一致（如索引是ASC，SQL却写DESC）时，极易触发。
实操建议：
- 把
JOIN条件、WHERE过滤、ORDER BY字段打包进一个联合索引，顺序按“等值条件→范围条件→排序字段”排列 - 避免
SELECT *，只取必要字段；若用到SELECT a, b, c，索引末尾可加上b, c实现覆盖，省去回表 - 检查
tmp_table_size和max_heap_table_size是否过小，太小会迫使临时表落地磁盘，反而放大CPU开销
没加索引的多表JOIN，实际执行可能是笛卡尔积
三张表A JOIN B JOIN C，如果任意两张之间缺失有效索引，MySQL优化器可能放弃使用索引，退化成嵌套循环+全表扫描。更危险的是：当某张表过滤后只剩几行，但另一张表没条件限制，就会产生爆炸式中间结果集——比如A剩2行、B剩3行、C有100万行，组合起来就是2×3×100万=600万行，CPU全耗在构造和过滤这个结果集上。
验证方式很简单：
- 执行
SHOW PROCESSLIST;，看状态是不是长时间卡在Sending data或Copying to tmp table - 查
information_schema.PROCESSLIST里的Info字段，复制出完整SQL，再EXPLAIN FORMAT=TRADITIONAL逐层看各表访问方式 - 注意
rows列不是静态值，它反映的是该表在当前JOIN顺序下的预估扫描行数，要结合table列一起读
IN子查询被重写成JOIN后失控，别信优化器自动改写
MySQL 5.7+会把某些IN (SELECT ...)自动转成semi-join，但一旦子查询结果集大、或外层没索引，这种改写反而让CPU更忙。典型表现是EXPLAIN里出现materialized或firstmatch，且rows暴涨。
更稳妥的做法是手动控制：
- 把
IN子查询拆出来，先CREATE TEMPORARY TABLE存结果，并在关键字段建索引 - 确认子查询是否真的需要实时执行；如果是固定维度（如地区列表），直接用
VALUES或JOIN字面量代替 - 用
STRAIGHT_JOIN强制驱动表顺序，防止优化器选错表做外层循环
真正难处理的从来不是单条慢SQL，而是那些看起来“只是多连了一张表”的查询——它们在数据量增长后悄然越过临界点，把CPU推到100%。盯紧EXPLAIN里的rows和Extra，比调参或升配管用得多。
