CROSS APPLY 能实现分组 Top N，但仅在分组数少、N 小、外层分组键完整且有索引时更合适；多数场景下比 ROW_NUMBER() 更慢、更难控、易丢数据。
直接说结论：CROSS APPLY 能实现分组 Top N，但“灵活”是有代价的——它只在特定条件下比 ROW_NUMBER() 更合适，多数时候反而更难控、更慢、更容易丢数据。
为什么 CROSS APPLY 的 Top N 看似灵活，实则受限
CROSS APPLY 本质是“为每个外层值执行一次子查询”，所以它的“灵活性”仅体现在：子查询里能用外层字段做参数、TOP 数量可动态（比如 TOP (a.num)），还能配合 OUTER APPLY 保留空分组。但它不等于通用解法：
- 外层必须提供完整、准确的分组键集合；若
SELECT DISTINCT dept_id FROM employees漏掉NULL或 JOIN 不全，对应分组就彻底消失 - 子查询必须带确定性
ORDER BY，否则TOP结果不可复现 - 无法处理并列名次（如工资相同要全取或去重），
TOP只认行数，不认逻辑排名 - SQL Server 不支持
OFFSET ... FETCH在CROSS APPLY子查询中使用，只能靠TOP
CROSS APPLY + TOP 动态控制 N 的写法要点
当真需要按不同分组取不同数量（比如销售部取前 5，行政部取前 2），必须把 N 存进关联表或用 CASE 计算，不能硬编码：
SELECT d.dept_name, a.emp_id, a.salary
FROM departments d
CROSS APPLY (
SELECT TOP (
CASE d.dept_name
WHEN 'Sales' THEN 5
WHEN 'HR' THEN 2
ELSE 3
END
) emp_id, salary
FROM employees e
WHERE e.dept_id = d.dept_id
ORDER BY salary DESC, emp_id ASC
) a;
注意：TOP 后面的括号不能省，且表达式必须返回整数；ORDER BY 里加 emp_id ASC 是为了打破并列时的不确定性。
性能陷阱：索引缺失会让 CROSS APPLY 变成全表扫描地狱
每执行一次内层子查询，SQL Server 都会尝试走索引查找——前提是 WHERE 条件字段（如 dept_id）上有索引。没有索引时：
- 外层有 1000 个部门 → 内层触发 1000 次全表扫描
- 员工表 100 万行 → 实际扫描行数可能达 10 亿级
- 哪怕
N=1，也比ROW_NUMBER()一次性扫描慢得多
验证方法：看执行计划里内层是否出现 Index Seek；如果全是 Table Scan 或 Clustered Index Scan，立刻停用 CROSS APPLY 方案。
什么时候该换回 ROW_NUMBER()？
遇到以下任一情况，CROSS APPLY + TOP 就该放弃：
- 分组数超过几百个（比如按日期+地区+产品三级分组）
-
N > 10（Top-20/Top-50 类需求） - 需要严格保证“恰好 N 条”或处理并列（
DENSE_RANK()/RANK()更可控） - 外层分组源不稳定（比如来自多表
JOIN，中间可能丢行）
最易被忽略的一点：很多人抄了 CROSS APPLY 示例却没检查外层 DISTINCT 是否覆盖全部业务分组值——漏掉的组不会报错，只会静默消失。而 ROW_NUMBER() 是全表驱动，天然保底。
