outer apply + top 1 必须配合 order by，否则结果不可靠；需按业务需求指定排序方向（如 desc 取最新），并建立以关联字段和排序字段为核心的覆盖索引，同时注意 outer apply 与 cross apply 在 null 处理上的语义差异。
OUTER APPLY + TOP 1 必须带 ORDER BY
不写 ORDER BY 的 TOP 1 是不可靠的——SQL Server 不保证返回哪一行，尤其当右侧表没有聚集索引或排序字段无索引时，结果可能每次执行都不一样。业务上要“最新订单”“最高分”“最早发货”，就必须显式声明排序方向。
-
ORDER BY CreatedDate DESC才能拿到最新；ASC拿到最早 - 多字段排序更稳妥，比如
ORDER BY Score DESC, Id ASC，避免并列时结果随机 - 如果排序字段允许 NULL，SQL Server 默认把 NULL 排最前（不管 ASC/DESC），需用
ORDER BY ISNULL(CreatedDate, '1900-01-01') DESC或计算列控制
右表必须有合适索引，否则性能崩盘
OUTER APPLY 的执行计划通常是嵌套循环（Nested Loops）+ 索引查找（Index Seek），但前提是右表的关联字段和排序字段组合有覆盖索引。没索引时，每左表一行都会触发一次右表全扫描，10 万用户 × 平均 5 条订单 = 50 万次扫描。
- 推荐索引：以关联字段为前导，排序字段紧跟其后，例如
(UserId, OrderDate DESC) - 若还要取其他字段（如
Amount），加到INCLUDE列里，避免键查找（Key Lookup） - 别只建
OrderDate单列索引——它无法支持WHERE UserId = ?的快速定位
OUTER APPLY 和 CROSS APPLY 的 NULL 处理差异直接影响结果
这是最容易被忽略的语义陷阱：OUTER APPLY 保留左表所有行，右表无匹配时字段为 NULL；CROSS APPLY 直接丢弃整行。选错会导致数据量凭空少掉一大截。
- 查“每个用户最新订单时间”，用
OUTER APPLY——没下单的用户也要显示，last_order是NULL - 查“每个有订单用户的最新订单详情”，用
CROSS APPLY——天然过滤掉无订单用户 - 别在 WHERE 里补
o.OrderId IS NOT NULL来模拟 CROSS APPLY，这会让优化器放弃嵌套循环，转而走哈希连接或排序，性能反而更差
想取 Top N（不止 1 条）？TOP 后必须加别名且字段显式命名
SELECT 列表里引用 OUTER APPLY 子查询的结果时，SQL Server 要求子查询输出字段有明确名称，否则报错 Invalid column name。而且 TOP 2 返回多行，外层必须能区分它们，不能直接 SELECT u.*, o.*。
- 子查询必须带表别名（如
o），且每个字段用AS命名，例如SELECT TOP 2 OrderId AS top2_id, Amount AS top2_amt - 如果要展开成多列（如 top1_id, top2_id），得用条件聚合或 PIVOT，OUTER APPLY 本身不提供列展开能力
- 别指望
TOP 2配合OUTER APPLY自动变成两行——它只返回一个结果集，最多含两行，但外层仍是一行拼接（除非你用UNION ALL拆开）
ROW_NUMBER() 往往比反复驱动的 OUTER APPLY 更可控。而 OUTER APPLY 的优势只在“小分组数 + 小 N + 强索引”这个狭窄窗口里成立。
