大数据环境下，SQL子查询全表扫描如何引发CPU激增，执行过程有何特点？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1139个文字，预计阅读时间需要5分钟。
子查询查询本身不会导致CPU飙升，但当它被优化器判定为无法下推或无法重写时，MySQL会退化为嵌套循环：
这种扫描不是“扫一次”，而是逐行触发、逐行解码、逐行条件比对，CPU 花在字符串比较、类型转换、内存拷贝上的时间远超 IO 等待。尤其当 rows 达到几十万级，EXPLAIN 的 filtered 又低于 10%，基本可断定是 CPU 瓶颈源头。
子查询未被优化器转成 JOIN，且无合适索引支撑
MySQL 5.7+ 对某些子查询（如非相关子查询、含 GROUP BY 或 DISTINCT 的）会尝试自动重写为 JOIN，但前提是子查询结果集小、字段有索引、且没有 ORDER BY / LIMIT 干扰。一旦失败，就会保留子查询结构，而优化器又选了错误的驱动表——比如拿大表做驱动，小表做子查询，导致小表被反复扫描。
本文共计1139个文字，预计阅读时间需要5分钟。
子查询查询本身不会导致CPU飙升，但当它被优化器判定为无法下推或无法重写时，MySQL会退化为嵌套循环：
这种扫描不是“扫一次”，而是逐行触发、逐行解码、逐行条件比对，CPU 花在字符串比较、类型转换、内存拷贝上的时间远超 IO 等待。尤其当 rows 达到几十万级，EXPLAIN 的 filtered 又低于 10%，基本可断定是 CPU 瓶颈源头。
子查询未被优化器转成 JOIN，且无合适索引支撑
MySQL 5.7+ 对某些子查询（如非相关子查询、含 GROUP BY 或 DISTINCT 的）会尝试自动重写为 JOIN，但前提是子查询结果集小、字段有索引、且没有 ORDER BY / LIMIT 干扰。一旦失败，就会保留子查询结构，而优化器又选了错误的驱动表——比如拿大表做驱动，小表做子查询，导致小表被反复扫描。