APPLY 不能替代 OFFSET-FETCH 分页，因其是行级连接而非分页机制；正确用法是先用 OFFSET-FETCH 分页主表，再用 APPLY 关联每行依赖子集，避免在子查询中误用 OFFSET 或重复排序。
APPLY 不能直接替代 OFFSET-FETCH 分页，但能安全改写「每行依赖子查询」的嵌套逻辑——尤其当子查询需引用外层字段时。
为什么不能用 APPLY 做通用分页？
APPLY（CROSS APPLY 或 OUTER APPLY）本质是行级连接，不是分页机制。它不提供跳过前 N 行、取 M 行的能力；强行用 TOP + ORDER BY 在子查询里模拟分页，会导致结果错乱（比如第 2 页可能重复或漏掉某些主表行）。
- 分页必须在最终结果集上统一排序并切片，而 APPLY 的子查询是按主表每行独立执行的
-
OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY是语义明确、可优化的分页标准写法 - 若你当前 SQL 报错
Incorrect syntax near 'OFFSET'，说明版本低于 SQL Server 2012 —— 此时才需考虑 APPLY 配合其他手段（如 ROW_NUMBER）补救
什么场景下该用 APPLY 替代子查询？
典型情况：外层查询每行需动态关联一组相关数据，且该组数据依赖外层字段（比如查每个订单的最新 3 条物流记录）。
- 原写法常是相关子查询：
(SELECT TOP 3 ... FROM Shipments s WHERE s.OrderID = o.OrderID ORDER BY s.CreatedAt DESC)，性能差、不可复用 - 改用
CROSS APPLY后，SQL Server 能更好生成执行计划，尤其配合索引（如Shipments(OrderID, CreatedAt DESC)） - 注意：子查询里必须有
ORDER BY才能保证TOP取的是“最新”而非随机几条
SELECT o.OrderID, o.Total, s.TrackingNo, s.Status
FROM Orders o
CROSS APPLY (
SELECT TOP 3 TrackingNo, Status
FROM Shipments s
WHERE s.OrderID = o.OrderID
ORDER BY s.CreatedAt DESC
) s;
用 APPLY 实现「带分页的关联数据」要避开哪些坑？
如果需求是「查第 2 页订单，且每个订单附带其最新 2 条日志」，不能把分页逻辑塞进 APPLY 子查询。
- 错误写法：
CROSS APPLY (SELECT TOP 2 ... ORDER BY LogTime DESC OFFSET 10 ROWS...)——OFFSET在子查询里非法，且语义错误 - 正确分层：先用
OFFSET-FETCH分页主表（Orders），再用APPLY关联每行所需子集 - 若主表分页后仍需对子集做分页（比如只取每个订单的第 2–3 条日志），子查询内只能用
ROW_NUMBER()过滤，不能用OFFSET
SELECT o.OrderID, l.LogText
FROM (
SELECT OrderID FROM Orders
ORDER BY OrderID
OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY
) o
CROSS APPLY (
SELECT LogText
FROM (
SELECT LogText, ROW_NUMBER() OVER (ORDER BY LogTime DESC) rn
FROM OrderLogs l
WHERE l.OrderID = o.OrderID
) t
WHERE t.rn BETWEEN 2 AND 3
) l;
兼容老版本（SQL Server 2005–2008 R2）的替代方案
这些版本不支持 OFFSET-FETCH，但支持 APPLY 和 ROW_NUMBER()。此时分页必须靠主查询包裹 ROW_NUMBER()，再用 WHERE rn BETWEEN X AND Y。
- APPLY 本身不解决分页，但能让子查询部分更可控、更易读
- 避免在
ROW_NUMBER()外层再套一层 APPLY 做分页——这会强制全表计算序号，性能灾难 - 务必确保
ORDER BY字段有索引，否则ROW_NUMBER()开窗成本极高
真正容易被忽略的是：APPLY 的子查询中若引用了外部聚合字段（如 o.TotalAmount），而主查询又用了 GROUP BY，就可能触发 Invalid column name 错误——因为 APPLY 在逻辑处理顺序上晚于 GROUP BY，但早于 SELECT 列别名解析。
