相关子查询导致cpu飙升，因其对主表每行重复执行子查询，引发逻辑读累积、解析开销和缓存失效；应改写为left join，并确保索引与统计信息准确。
相关子查询本身不是语法错误，但它是数据库CPU飙升的常见元凶——尤其当主表返回行数多、子查询又没走索引时，CPU会在线性增长中失控。
为什么相关子查询会让CPU飙升
核心问题在于执行机制：数据库对主表每一行都重新执行一次子查询，而不是复用结果。这带来三重开销：
- 逻辑读累积：比如主表返回 5000 行，
(SELECT name FROM dept WHERE deptno = e.deptno)就会被调用 5000 次，即使deptno只有 20 个不同值 - 解析与计划重编译开销：SQL Server 2022 默认按“嵌套循环”建模，优化器常低估重复执行的 CPU 成本
- 缓存失效：每次执行都可能触发新页加载、Buffer Pool 冲突，加剧内存压力
典型现象包括：EXPLAIN 中出现大量 Compute Scalar + Clustered Index Seek 组合；STATISTICS IO 显示子查询部分逻辑读远超主表扫描；CPU 时间随主结果集行数线性上升。
标量子查询必须改写为 LEFT JOIN
这是最直接、最可控的解法。不能简单替换成 INNER JOIN，否则语义不等价：
- 原语句
(SELECT dname FROM dept WHERE deptno = e.deptno)在e.deptno无匹配时返回NULL，对应的是LEFT JOIN - 若确认外键约束存在且无空值，可尝试
INNER JOIN获取更优执行计划，但需业务侧确认容忍数据过滤 - 子查询含
TOP 1、ORDER BY或聚合（如MAX(sal)）时，不能直连，要先用 CTE 或派生表预聚合
示例改写：
SELECT e.ename, (SELECT d.dname FROM dept d WHERE d.deptno = e.deptno) AS dname
FROM emp e
WHERE e.job IN ('SALESMAN', 'ANALYST');
→ 改为：
SELECT e.ename, d.dname
FROM emp e
LEFT JOIN dept d ON d.deptno = e.deptno
WHERE e.job IN ('SALESMAN', 'ANALYST');
WHERE 中的 EXISTS/IN 嵌套必须拆成显式 JOIN
像 WHERE CustomerID IN (SELECT CustomerID FROM Customers WHERE City IN (SELECT City FROM Suppliers WHERE Country = 'USA')) 这类写法，在执行计划里极易退化为 N² 级扫描。优化关键是切断嵌套链：
- 从最内层开始，确保
Suppliers.Country有索引；中间层Customers.City必须有索引；外层关联字段（如Orders.CustomerID）也需索引 - 改写为链式 JOIN：
Suppliers → Customers → Orders，让优化器能走Index Nested-Loop Join - 避免
SELECT *，只取必要字段，减少 Join Buffer 占用和内存拷贝
如果数据库支持（如 PostgreSQL 12+、MySQL 8.0+），LATERAL JOIN 是更清晰的替代方案，语义明确且更容易命中索引。
容易被忽略的细节：统计信息和执行计划回归
即使你写了正确的 LEFT JOIN，如果 dept 表统计信息过期，优化器仍可能选择 Hash Match 而非 Index Seek，导致全表扫描。更隐蔽的是执行计划回归：昨天还走索引，今天因统计信息更新或参数嗅探换了计划，性能突然坍塌。所以优化后必须查 EXPLAIN 确认是否真走了索引，并长期启用 Query Store（SQL Server）或 pg_stat_statements（PostgreSQL）监控计划变更。没有基线对比，就等于在盲修。
