SQL Server的UPDATE语句不支持直接使用ORDER BY，因子查询中ORDER BY必须配合TOP、OFFSET/FETCH或窗口函数OVER()，否则报错；正确做法是用ROW_NUMBER() OVER(ORDER BY ...)在CTE中排序编号，再更新指定行号记录。
不能直接用 ORDER BY 更新单条记录，必须借助窗口函数或派生表实现排序定位。SQL Server 的 UPDATE 语句本身不支持 ORDER BY 子句（除非配合 TOP），更不允许在子查询中裸写 ORDER BY 而不加 TOP 或 OFFSET/FETCH —— 否则会报错 "The ORDER BY clause is invalid in views, inline functions, derived tables, subqueries, and common table expressions..."。
为什么 UPDATE + ORDER BY 子查询会报错
SQL Server 在解析子查询时，若其中含 ORDER BY 却没搭配 TOP、OFFSET 或用于窗口函数的 OVER()，就会拒绝执行。这不是语法疏漏，而是设计限制：子查询的结果集本无序，强制排序却无上下文（比如取第几行），引擎无法确定语义。
常见错误写法示例：
UPDATE t SET status = 'processed' FROM orders t WHERE t.order_id IN ( SELECT order_id FROM orders WHERE status = 'pending' ORDER BY created_date ASC );
上面这段会直接报错。关键点在于：ORDER BY 出现在非 TOP/窗口上下文中。
用 ROW_NUMBER() + CTE 实现“按排序更新前 N 条”
这是最可靠、可读性高且兼容 SQL Server 2019 的做法。核心是把排序逻辑放进 OVER()，用 ROW_NUMBER() 标记顺序，再在外部 UPDATE 中筛选行号。
例如：更新最早创建的 5 条待处理订单
WITH ranked AS (
SELECT order_id, status,
ROW_NUMBER() OVER (ORDER BY created_date ASC) AS rn
FROM orders
WHERE status = 'pending'
)
UPDATE ranked
SET status = 'processing'
WHERE rn <= 5;
-
ROW_NUMBER()必须配合OVER(ORDER BY ...)，不能单独用 - CTE 中的
WHERE要提前过滤，避免对全表排序增加开销 - 如果存在相同
created_date，ROW_NUMBER()仍会强制编号（稳定但非业务意义“并列”）；需并列可用RANK()，但注意它会导致跳号 - 该写法可安全用于生产环境，执行计划通常能走索引（前提是
created_date有索引）
用 TOP + 子查询绕过 ORDER BY 限制（仅限单次更新）
当只需更新“排序后第一条”或固定数量时，TOP 是轻量替代方案，但要注意它不保证可重复性（无 ORDER BY 时行为不确定）。
正确写法（带 ORDER BY）：
UPDATE TOP (1) orders SET status = 'processing' WHERE status = 'pending' ORDER BY created_date ASC;
⚠️ 注意：
-
TOP必须紧跟UPDATE，不能写在子查询里 -
ORDER BY在 UPDATE 语句末尾是允许的，且是必要条件——否则TOP (1)没有意义 - 不支持 “更新第 2 到第 5 条”，这种场景必须退回 CTE +
ROW_NUMBER() - 如果表有触发器，
TOP更新可能影响触发器逻辑（因实际更新行数不确定）
容易被忽略的细节：ORDER BY 字段缺失索引 & NULL 处理
排序字段没索引，ROW_NUMBER() 或 TOP ... ORDER BY 都会触发全表扫描或大排序操作，尤其在百万级订单表上可能卡住事务。
另外，NULL 值默认排在最前（ASC）或最后（DESC），但如果你的业务要求 NULL 排最后（ASC 场景），得显式控制：
ORDER BY CASE WHEN created_date IS NULL THEN 1 ELSE 0 END, created_date ASC
还有个隐形坑：UPDATE ... FROM 语法中若 JOIN 了多个表，ORDER BY 不能引用 JOIN 后的别名字段（除非包裹进 CTE），否则报错或结果不可控。
