关联子查询改写为JOIN通常可显著提升性能，因其避免了逐行执行内层查询的嵌套循环开销；但需注意NULL处理、重复行、索引缺失及统计信息陈旧等风险。
直接把关联子查询改写成 JOIN，绝大多数情况下就能解决性能问题。SQL Server 2016 的优化器对 JOIN 的物理执行路径（比如哈希联接、合并联接）支持更成熟，而关联子查询常被退化为嵌套循环，逐行触发内部查询，I/O 和 CPU 开销会指数级上升。
为什么关联子查询在 SQL Server 2016 中容易变慢
核心原因是执行模型不同：关联子查询的语义是“对外层每一行，执行一次内层查询”，哪怕内层只查一个标量值，也会重复解析、编译（若未参数化）、扫描或索引查找。尤其当外层结果集有上万行，而内层又没走索引时，SELECT ... WHERE x = (SELECT y FROM t2 WHERE t2.id = t1.ref) 就可能变成上万次独立的小查询。
常见错误现象包括：
- 执行计划里出现大量
Nested Loops算子，且内侧输入显示“Compute Scalar”或反复调用Index Seek -
Actual Rows明显远大于Estimated Rows，说明统计信息失效或优化器误判 - IO 统计中
logical reads高得异常，比如单条语句读取百万页
标量子查询转 LEFT JOIN 的实操步骤
适用于形如 SELECT a.*, (SELECT b.name FROM b WHERE b.id = a.b_id) AS b_name FROM a 这类场景。关键不是简单替换，而是处理 NULL 和多行报错风险：
- 先确认子查询是否真的「保证单行」：检查
b.id是否为主键或带唯一约束；否则加TOP (1)并接受不确定性，或改用聚合（如MAX(b.name)） - 用
LEFT JOIN替代，避免因b缺失导致整行丢失：FROM a LEFT JOIN b ON a.b_id = b.id - 如果原语句用
WHERE col = (SELECT ...)且子查询可能返回 NULL，注意JOIN后该条件需显式写成WHERE b.id IS NOT NULL或保留原逻辑分支 - 别忘了给
b.id字段建索引——这是改写后能提速的前提，否则JOIN仍会走全表扫描
EXISTS/IN 类子查询优先用半联接（Semi-Join）重写
像 SELECT * FROM orders WHERE cust_id IN (SELECT id FROM customers WHERE status = 'active') 这类，SQL Server 2016 能自动将部分 IN 优化为 Hash Match (Inner Join)，但前提是子查询不带复杂表达式。手动优化更可控：
- 用
EXISTS替代IN：语义等价且通常生成更优计划，尤其当子查询列有 NULL 时IN行为难预测 - 进一步拆解为显式
INNER JOIN+DISTINCT（仅当需要去重时），但要注意：如果外层本来就有重复cust_id，JOIN会放大结果集，此时必须加DISTINCT或改用EXISTS - 若子查询含聚合（如
SELECT cust_id FROM orders GROUP BY cust_id HAVING SUM(amount) > 1000），先把它物化到临时表并建索引，再与主表JOIN，比嵌套执行快一个数量级
改写后必须验证的三个点
很多人改完就上线，结果数据不对或性能更差。最容易被忽略的是：
- 空值处理差异：
(SELECT name FROM b WHERE id = a.b_id)返回 NULL 当无匹配；而LEFT JOIN后b.name是 NULL，看起来一样，但如果原查询在WHERE中用了IS NOT NULL，JOIN版本必须显式补上，否则逻辑错 - 重复数据放大：
JOIN可能因一对多关系导致外层一行变多行，而子查询不会——这是最隐蔽的 Bug 来源 - 统计信息陈旧：改写后首次执行可能仍沿用旧计划缓存，务必运行
UPDATE STATISTICS或至少加OPTION (RECOMPILE)测试真实性能
