标量子查询在select中极慢，因其强制每行重复执行子查询且无法复用计划；必须改：引用外层字段且外层行数＞100、含top 1 order by但无合适索引、多个标量子查询共存；可保留：纯常量或不依赖外层的固定值查询。
标量子查询在SELECT里为什么一用就慢
因为SQL Server（以及PostgreSQL、Oracle等主流引擎）对SELECT列表里的标量子查询，基本只能走嵌套循环执行——外层每返回1行，内层子查询就重新执行1次，且无法共享执行计划或下推过滤条件。哪怕子查询本身只查10ms，外层返回1万行，总耗时就是100秒。
典型症状包括：Compute Scalar节点高频出现、执行计划中大量Clustered Index Scan或Index Scan、监控看到CPU持续打满但IO不高。这不是语句写错，是语义本身触发了最差的执行路径。
什么情况必须改，什么情况可以留着不动
需要立刻重构的场景：
- 子查询引用了外层表字段（如
WHERE o.user_id = u.id），且外层结果集 > 100行 - 子查询含
TOP 1 ... ORDER BY但没配好索引，执行计划显示Sort或Table Scan - 同一查询里出现2个及以上标量子查询（如查最新订单时间 + 最新订单金额），性能会指数级恶化
可以暂时保留的场景：
- 子查询是纯常量，如
(SELECT GETDATE())或(SELECT 100 * 0.05) - 子查询不依赖外层表，如
(SELECT MAX(price) FROM products)，这种会被优化器提前物化为InitPlan - 外层表极小（
OUTER APPLY替代的实操要点
这是最直接有效的替换方案，但不是简单改语法就能生效：
- 右表子查询必须加别名（如
o），且字段要显式命名（AS last_order），否则外层无法引用 -
TOP 1和ORDER BY必须共存；排序字段最好落在索引右侧，例如复合索引(user_id, order_date DESC) - 索引必须覆盖查找+排序+输出字段：对
WHERE o2.user_id = u.id ORDER BY order_date DESC，最优索引是CREATE NONCLUSTERED INDEX IX_orders_user_date ON orders (user_id) INCLUDE (order_date) - 如果业务允许无订单用户显示
NULL，用OUTER APPLY；否则用CROSS APPLY，但会丢掉无匹配的外层行
原始写法：
SELECT u.id, u.name, (SELECT TOP 1 order_date FROM orders o WHERE o.user_id = u.id ORDER BY order_date DESC) AS last_order FROM users u
改写后：
SELECT u.id, u.name, o.last_order FROM users u OUTER APPLY ( SELECT TOP 1 order_date AS last_order FROM orders o2 WHERE o2.user_id = u.id ORDER BY order_date DESC ) o
比OUTER APPLY更轻量的替代方案
当标量子查询本质是“按组聚合”，而非“逐行关联取值”时，JOIN预聚合更高效：
- 把
(SELECT AVG(salary) FROM emp e2 WHERE e2.dept_id = e1.dept_id)改成先算好部门均值再LEFT JOIN - 用CTE固化中间结果，尤其当同一子查询在多个地方复用（如SELECT列表+WHERE条件）
- 对固定值类计算（如税率、配置项），直接用变量或
CROSS JOIN，避免任何运行时查表
关键判断点：如果子查询的WHERE条件只依赖外层某一个字段（如dept_id），且该字段基数不高（比如部门数
真正容易被忽略的是索引设计——即使语法完全正确，OUTER APPLY没有覆盖索引，照样退化成全表扫描。别只盯着SQL怎么写，先看EXEC sp_helpindex 'orders'输出里有没有那个INCLUDE字段。
