SQL Server中ROW_NUMBER()不能直接用于UPDATE，因窗口函数仅允许出现在SELECT和ORDER BY子句；必须通过CTE先计算排名，再关联主键更新。
ROW_NUMBER() 不能直接用于 UPDATE 语句
SQL Server 不允许在 UPDATE 中直接使用窗口函数（如 ROW_NUMBER()）作为赋值表达式。你如果写了类似 UPDATE t SET rank = ROW_NUMBER() OVER (ORDER BY insert_time)，会收到错误：Windowed functions can only appear in the SELECT or ORDER BY clauses。这不是语法写错，是引擎限制——窗口函数只能出现在 SELECT 和 ORDER BY 中。
真正可行的路径只有一条：用 CTE（公用表表达式）把带排名的行先“算出来”，再通过 JOIN 或子查询更新原表。
用 CTE + UPDATE 关联实现安全更新
这是最常用、最可控的方式。关键点在于：CTE 必须包含能唯一标识每一行的列（如主键或唯一约束列），否则 UPDATE 可能误匹配或多匹配。
-
INSERT_TIME字段必须有定义且非 NULL；若存在相同时间戳，ROW_NUMBER()的排序结果不确定，建议追加主键列保序：ORDER BY insert_time, id - CTE 中的别名（如
ranked）不能省略，否则后续UPDATE无法引用 -
UPDATE必须显式指定目标表别名，并与 CTE 关联（通常用主键）
WITH ranked AS ( SELECT id, ROW_NUMBER() OVER (ORDER BY insert_time, id) AS new_rank FROM your_table ) UPDATE t SET rank = r.new_rank FROM your_table t INNER JOIN ranked r ON t.id = r.id;
为什么不用子查询或临时表？
子查询方式（如 UPDATE SET rank = (SELECT ...)）在大数据量下性能急剧下降，因为每行都触发一次子查询执行；临时表虽可行，但引入额外 I/O 和事务复杂度，且需手动清理。CTE 是逻辑视图，不落盘，配合主键 JOIN，执行计划通常走索引查找，效率和可读性更优。
注意一个典型陷阱：如果 your_table 没有合适聚集索引（比如按 insert_time 或 id 排序），ROW_NUMBER() 排序成本高，建议检查执行计划中是否出现“Sort”警告操作符。必要时可添加覆盖索引：CREATE INDEX IX_insert_time_id ON your_table(insert_time, id)。
插入新数据后如何增量更新排名？
全量重算排名在高频写入场景下不可取。更实际的做法是：只更新新增行及其后受影响的行。但 SQL Server 没有内置“排名偏移”机制，所以常见策略是预留空档或用稀疏编号（如每次插值加 100），避免频繁重排。若必须严格连续排名，推荐在应用层控制插入顺序，并在插入时直接计算 new_rank = (SELECT ISNULL(MAX(rank), 0) + 1 FROM your_table) —— 这要求业务能接受串行插入或加应用锁。
另一个现实约束：如果表上有并发插入，ROW_NUMBER() 基于当前快照，两次执行结果可能不同。别指望它实时反映“最新插入顺序”，除非你在事务中完成插入+更新+提交三步，并用 WITH (TABLOCKX) 阻塞其他写入——但这会严重降低吞吐。
