SQL Server 2019三层以上嵌套子查询易因优化器放弃估算而选错执行路径，需人工物化最内层为带索引的临时表并启用兼容性级别150以激活IQP功能。
SQL Server 2019 对三层以上嵌套子查询的执行计划常失效——不是你写得错，是优化器主动放弃精确估算，直接选错连接顺序、索引路径或强行走 Nested Loops。必须人工干预，不能等自动优化。
看到 Rebinds > 1 就该立刻停手
执行前加 SET STATISTICS PROFILE ON，跑完看实际执行计划里的 Rebinds 值。只要某个子查询节点的 Rebinds 远大于 1（比如 5000+），说明它被外层每行都重算一次，已进入雪崩状态。
- 常见诱因：
WHERE id IN (SELECT user_id FROM logs WHERE status = u.status)—— 引用了外层列u.status，必触发重复执行 - 带非确定性函数也会强制不可缓存：
GETDATE()、NEWID()、未参数化的变量（如拼接字符串） -
Compute Scalar下嵌套Table Spool (Lazy Spool)是典型 UNCACHEABLE SUBQUERY 信号，每次调用都从头算
用 SELECT INTO #tmp 物化最内层，别信“看起来像 JOIN 就安全”
把最深、最稳定、结果集可控的那层子查询拎出来，显式物化为临时表。这比依赖优化器自动物化可靠得多，且能彻底扁平执行路径。
- 写法示例：
SELECT user_id, COUNT(*) AS cnt INTO #user_order_cnt FROM orders GROUP BY user_id - 必须立刻建索引：
CREATE CLUSTERED INDEX IX_user_order_cnt_user_id ON #user_order_cnt(user_id)，否则后续JOIN仍退化为扫描 - 外层改用
JOIN #user_order_cnt替代原嵌套，索引、统计信息、行估算全部回归可控范围 - 注意：物化后要验证语义一致性，尤其 NULL 处理和空关联场景（如某用户无订单时是否应保留）
OUTER APPLY 比标量子查询更可控，但右表索引必须覆盖
把 SELECT 列中类似 (SELECT TOP 1 order_date FROM orders o WHERE o.user_id = u.id ORDER BY order_date DESC) 的写法，换成 OUTER APPLY，能明确表达“每行执行一次”，避免优化器误判为不可复用逻辑。
- 关键前提：右表（
orders）必须有复合索引，如INDEX IX_orders_user_date ON orders(user_id, order_date DESC) - 字段必须显式命名：
AS last_order，否则外层无法引用 -
TOP 1 + ORDER BY必须共存，否则 SQL Server 可能忽略排序，取物理第一行 - 若业务允许丢弃无匹配记录，用
CROSS APPLY；需保留主表所有行（补 NULL），才用OUTER APPLY
兼容性级别不设成 150，IQP 功能全白搭
ALTER DATABASE [your_db] SET COMPATIBILITY_LEVEL = 150 不是可选项，是 IQP（智能查询处理）生效的前提。低于这个值，交错执行、自适应联接等功能压根不触发。
- 改完必须清缓存：
DBCC FREEPROCCACHE，否则旧计划继续复用 - 交错执行（Interleaved Execution）只对 MSTVF（多语句表值函数）有效，对 STVF 或内联 TVF 无效
- 自适应联接仅在批处理模式（Batch Mode）下工作，普通行模式（Row Mode）下依然走 Nested Loops，IQP 不干预
深层嵌套真正难的不是语法改写，而是判断哪一层该物化、哪一层该拉平、哪一层其实该砍掉——执行计划里看不到的 NULL 传播、条件下推失败、字段别名模糊，往往比性能慢更致命。
