CROSS APPLY 不能直接用于 UPDATE 的 FROM 子句，必须包裹在子查询或 CTE 中，返回目标表主键及待更新字段，再通过 JOIN 关联更新；否则报语法错误或标识符绑定失败。
用 CROSS APPLY 做 UPDATE 时必须套子查询
CROSS APPLY 本身不能直接出现在 UPDATE 的 SET 或 FROM 子句中——SQL Server 不允许在 UPDATE ... FROM 中把 CROSS APPLY 当作顶层表源。你得把它包进一个派生表（子查询）或 CTE 里，再让 UPDATE 引用这个中间结果。
常见错误现象：Incorrect syntax near 'CROSS' 或 The multi-part identifier "xxx" could not be bound，基本都是因为试图在 UPDATE FROM 后直接写 CROSS APPLY。
- 正确姿势：先用子查询或 CTE 把
CROSS APPLY的结果算出来，给每一行带上目标表的主键（或唯一关联字段）和要更新的值 - UPDATE 的 FROM 必须能明确关联到原表——通常靠 JOIN 到子查询的 key 字段
- 别漏掉 WHERE 条件限制影响范围，否则可能误更新整张表
UPDATE + 子查询 + CROSS APPLY 的标准写法
这是最稳妥、兼容性最好的方式，适用于 SQL Server 2005+。核心是让子查询返回 id（目标表主键）和待更新字段值，然后 UPDATE 关联它。
UPDATE t
SET t.status = src.new_status,
t.updated_at = GETDATE()
FROM orders t
INNER JOIN (
SELECT o.id,
ca.new_status
FROM orders o
CROSS APPLY (
SELECT TOP 1 status AS new_status
FROM order_logs l
WHERE l.order_id = o.id
ORDER BY l.created_at DESC
) ca
WHERE o.status IN ('pending', 'processing')
) src ON t.id = src.id;
注意点：
-
CROSS APPLY内部的子查询必须能关联外层o（比如用l.order_id = o.id），否则会变成笛卡尔积 - 外部子查询里要显式 SELECT 出原表的 key（这里是
o.id），UPDATE 才能对得上行 - 如果
CROSS APPLY可能不返回行（比如没日志），那这行就不会被 UPDATE 到——CROSS APPLY天然过滤，要用OUTER APPLY保留空结果
用 CTE 替代子查询更易读，但有执行计划风险
CTE 写法逻辑更清晰，尤其当 CROSS APPLY 部分较复杂时。但它不是物化视图，SQL Server 可能将 CTE 内联展开，导致重复计算或意外的连接顺序。
WITH update_src AS (
SELECT o.id,
ca.new_status
FROM orders o
CROSS APPLY (
SELECT TOP 1 status AS new_status
FROM order_logs l
WHERE l.order_id = o.id
ORDER BY l.created_at DESC
) ca
WHERE o.status IN ('pending', 'processing')
)
UPDATE t
SET t.status = src.new_status,
t.updated_at = GETDATE()
FROM orders t
INNER JOIN update_src src ON t.id = src.id;
性能提示：
- 确保
order_logs.order_id和created_at有联合索引（如IX_order_logs_order_id_created_at） - 如果
CROSS APPLY里用了聚合或窗口函数，CTE 可能比子查询更难优化，建议看执行计划里的“实际行数”是否爆炸 - 大表慎用——先在小数据集上测试逻辑和性能，
CROSS APPLY对每行都触发一次子查询，N × M 复杂度容易拖慢
替代方案：用 MERGE 配合 CROSS APPLY 更安全？
MERGE 理论上支持在 USING 子句里直接接 CROSS APPLY，但实测 SQL Server 2019+ 才稳定支持，旧版本常报错或行为异常。不推荐为这点“简洁”牺牲兼容性和可维护性。
真正容易被忽略的是：批量更新时，CROSS APPLY 的子查询若依赖未索引字段、或含非SARGable 条件（比如 WHERE YEAR(created_at) = 2024），性能会断崖下跌。别只盯着语法通不通，先看执行计划里有没有 “Table Scan” 或 “Index Scan” 占大头。
