CROSS APPLY在视图中易失控，因其右侧逻辑随外层查询内联展开，导致重复计算、行数误估、索引下推受阻及执行计划退化，尤其当右侧含聚合、排序或嵌套视图时。
视图中用 CROSS APPLY 不一定慢，但容易在不经意间触发隐式行集展开、重复计算或阻断索引下推，导致执行计划退化——尤其是当右侧子查询依赖外部列且无法被优化器提前估算行数时。
为什么CROSS APPLY在视图里容易失控
SQL Server 视图本身不存储数据，只是保存 SELECT 语句的“定义”。一旦视图被引用（比如 SELECT * FROM dbo.vw_sales_summary），整个定义会被内联展开到外层查询中。如果视图里有 CROSS APPLY，它的右侧逻辑就可能被多次求值，或与外层 JOIN/WHERE 条件耦合后失去优化空间。
- 右侧子查询若含聚合、排序、窗口函数，又没被外层 WHERE 过滤掉，就会对每一行都执行一次
- 优化器无法准确预估
CROSS APPLY右侧的输出行数，常误判为高开销操作，放弃并行或跳过索引查找 - 当视图被嵌套调用（比如 A 视图引用 B 视图，B 里有
CROSS APPLY），展开后逻辑爆炸，执行计划变得不可读也不可控
CROSS APPLY vs. INNER JOIN：关键区别在哪
CROSS APPLY 和 INNER JOIN 表面结果相似，但语义和优化路径完全不同：
-
INNER JOIN是基于等值或范围条件的集合关联，优化器可利用统计信息+索引做哈希/嵌套循环/合并连接 -
CROSS APPLY表达的是“对左侧行逐行调用右侧逻辑”，即使右侧是简单子查询（如(SELECT TOP 1 ... WHERE t.id = o.order_id)），也会被标记为“相关子查询”，限制优化自由度 - 右侧若含
ORDER BY + TOP，SQL Server 必须保证每行都跑一遍排序——哪怕最终只取 1 行，也无法下推过滤条件
如何快速判断是不是它拖慢了查询
别猜，直接看执行计划和 DMV 数据：
- 运行
sys.dm_exec_requests查询，找total_elapsed_time高且logical_reads异常大的会话，提取statement_text，确认是否命中含CROSS APPLY的视图名 - 查
sys.dm_exec_query_stats中该视图对应语句的avg_logical_reads和avg_elapsed_time，对比同类简单 JOIN 查询，高出 3 倍以上就值得怀疑 - 在执行计划 XML 中搜索
Apply节点，观察其EstimateRows是否远低于实际（比如预估 1 行，实际输出 5000 行），这是典型参数嗅探+行数误估信号
真正麻烦的不是 CROSS APPLY 本身，而是它藏在视图里，被业务代码无感调用——你改一行应用 SQL，可能触发整个视图重编译，而执行计划缓存里的旧计划还在悄悄拖垮 TEMPDB 和 CPU。动手前，先用 sys.dm_db_task_space_usage 确认是不是它在疯狂分配页。
