标量子查询放在where中会因每行重复执行而拖慢cpu，应移至select或用join预计算；关联子查询易引发嵌套循环，需谨慎使用并确保关联字段有索引；all/any隐式排序、派生表缺乏谓词下推均导致高cpu消耗。
标量子查询在WHERE里为什么容易拖慢CPU
标量子查询（比如 (SELECT AVG(score) FROM exam)）放在 WHERE 条件中，看似简洁，实际会让数据库对主表每一行都执行一次子查询——哪怕结果完全一样。如果主表有10万行，这个子查询就被重复执行10万次，CPU全花在反复计算和上下文切换上。
常见错误现象：EXPLAIN 显示 type=ALL 且 Extra 出现 Using where; Using subquery，rows 值巨大，但 filtered 很低。
- 把标量子查询移到
SELECT列表或用JOIN预计算，避免逐行调用 - 确认子查询是否真需要“每行重算”：多数场景下，它只该算一次，比如全局平均值、最大ID等
- 若必须关联计算（如“每个部门的平均分”），改用
JOIN或窗口函数AVG() OVER (PARTITION BY dept)，让优化器一次性完成聚合
关联子查询（Correlated Subquery）怎么写出高CPU陷阱
关联子查询依赖外部行（如 WHERE score > (SELECT AVG(score) FROM exam e2 WHERE e2.dept = e1.dept)），本质是嵌套循环：外层扫一遍，内层为每行再扫一遍。当两张表都超万行，复杂度接近 O(n×m)，CPU很快飙到100%。
使用场景判断：只有当业务逻辑**必须逐行比对**（例如“找出每个用户最近一笔订单”）才考虑关联子查询；否则一律先评估能否转成 JOIN 或 EXISTS。
-
EXISTS通常比IN更高效，尤其子查询结果集大时——它找到第一个匹配就退出，不穷举 - 确保关联条件字段（如上面的
e2.dept）上有索引，否则内层扫描变成全表扫 - 避免在关联子查询里再套聚合（如
MAX()+GROUP BY），这会让执行计划退化成多次临时表构建
ALL/ANY/SOME 子查询里的隐式排序开销
> ALL (SELECT price FROM products) 看似只是比较，但 SQL Server 和 MySQL 实际会先把子查询结果排序（为了快速取最大/最小），哪怕你只关心“是否大于全部”。排序操作直接吃掉大量 CPU，尤其子查询返回上千行时。
参数差异明显：> ANY 等价于 > MIN()，> ALL 等价于 > MAX()——但数据库不一定自动优化成聚合，取决于版本和统计信息。
- 显式改写为聚合函数：
> (SELECT MAX(price) FROM products)，强制走单值计算，跳过排序 - 检查执行计划中的
Extra是否含Using filesort，有则说明正在排序 - 如果子查询本身带
WHERE过滤，确保过滤字段已建索引，否则排序前还得先扫全表
子查询放FROM子句时为何还卡
把子查询当派生表（FROM (SELECT ... ) AS t）本意是“先算完再连”，但若子查询没加索引、或结果集太大没走内存排序，数据库仍可能生成临时表（Using temporary），导致CPU飙升。
性能影响关键点：派生表无法被外部查询的谓词下推（push-down），也就是说，WHERE 条件不能提前过滤子查询结果，只能等整个子查询执行完再筛。
- 优先用 CTE（
WITH）替代嵌套FROM子查询，部分引擎（如 SQL Server 2017+）能更好优化 CTE 的物化时机 - 子查询内部必须有明确的
WHERE或TOP限制，避免无意义全量计算 - 若派生表只用于
JOIN，确认连接字段在子查询里已存在且有索引，否则JOIN阶段又触发二次扫描
