SQL Server中CROSS APPLY不能直接用于UPDATE语句，因其语法禁止目标表出现在FROM子句中与APPLY关联；正确做法是用CTE预计算再JOIN更新，或改用子查询、窗口函数等更高效方式。
SQL Server里CROSS APPLY不能直接用于UPDATE语句
CROSS APPLY 本身是表值函数或子查询的横向关联操作符，它不支持出现在 UPDATE 的 FROM 子句右侧作为被更新目标的“源”。你写 UPDATE t SET ... FROM t CROSS APPLY (...) AS x 看似合理，但 SQL Server 会报错：The target table 't' of the INSERT/UPDATE/DELETE statement cannot be on either side of a FROM clause when using CROSS APPLY or OUTER APPLY.
常见错误场景：想对主表每行调用一个标量计算（比如查最新订单时间、聚合子表统计），再用结果批量更新主表字段——这时候误以为 CROSS APPLY 可以“带出”计算值并直接赋值。
- 根本原因：UPDATE 的 FROM 不允许对目标表做 APPLY 关联，这是语法硬限制
- 替代思路不是“绕过限制”，而是把 APPLY 的逻辑提前物化成可 JOIN 的中间结果
- 如果强行在 UPDATE 中嵌套 APPLY，SQL Server 会拒绝解析，不进执行计划阶段
用CTE + CROSS APPLY预计算再JOIN更新
真正可行的做法是：先用 CTE 把 CROSS APPLY 的结果算出来，给每一行挂上要更新的值，再和原表 JOIN 更新。这既保持了 APPLY 的灵活性，又符合 UPDATE 语法。
WITH calc AS (
SELECT
t.id,
t.name,
x.last_order_date,
x.order_count
FROM orders_summary t
CROSS APPLY (
SELECT
MAX(o.order_date) AS last_order_date,
COUNT(*) AS order_count
FROM orders o
WHERE o.customer_id = t.customer_id
AND o.status = 'shipped'
) x
)
UPDATE t
SET
latest_shipped_order = c.last_order_date,
shipped_order_count = c.order_count
FROM orders_summary t
INNER JOIN calc c ON t.id = c.id;
- 关键点：CTE 中的
CROSS APPLY只负责生成临时列，不触碰目标表 - UPDATE 时用标准
INNER JOIN关联 CTE 结果，安全且语义清晰 - 注意 CTE 必须包含足够 JOIN 条件（如
t.id），否则更新可能多对一或漏行
替代方案：用子查询或窗口函数更轻量
如果只是单值聚合（如 MAX、COUNT），多数情况不需要 CROSS APPLY。子查询或窗口函数更简洁、性能更好，也避免 CTE 多一层嵌套。
例如更新最新订单时间：
UPDATE t
SET latest_shipped_order = (
SELECT MAX(o.order_date)
FROM orders o
WHERE o.customer_id = t.customer_id
AND o.status = 'shipped'
)
FROM orders_summary t;
- 子查询方式在小数据量下可读性高，SQL Server 能自动优化为半连接（semi-join）
- 若需多个聚合字段（如同时要 MAX 和 COUNT），子查询会重复扫描，此时 CTE + APPLY 更优
- 窗口函数只适用于能用 PARTITION BY 的场景，比如更新“每个客户第 N 笔订单的标记”，但不能替代 APPLY 的复杂表值逻辑
容易忽略的性能陷阱
CROSS APPLY 在 CTE 中看似无害，但每行都会触发一次子查询执行——如果子查询没走索引或返回大量数据，整体更新可能慢得超预期。
- 检查子查询里的 WHERE 条件是否命中索引，特别是
o.customer_id和o.status组合索引 - 避免在 APPLY 中做 ORDER BY + TOP 1 替代 MAX，除非真需要“某一条记录的完整字段”，否则纯聚合更快
- UPDATE 前加
OPTION (RECOMPILE)有时能提升计划质量，尤其当参数敏感或统计信息滞后时 - 大数据量更新建议分批，不要让单次 CTE + UPDATE 锁住整个
orders_summary表
真正难的从来不是写出 CROSS APPLY，而是判断它是不是当前问题的最优解——很多时候，一个带索引的子查询，比包装三层的 APPLY 更稳、更快、更容易维护。
