不能。主流数据库禁止在UPDATE或DELETE中直接使用窗口函数，因其执行模型与窗口函数依赖的完整排序上下文冲突；MySQL 8.0+需用CTE预计算再JOIN更新，并确保CTE含唯一标识列以正确关联。
不能。所有主流数据库（MySQL、PostgreSQL、SQL Server、Oracle）都禁止在 UPDATE 或 DELETE 语句中直接使用窗口函数，这不是语法错误，而是执行模型层面的硬性限制。
为什么窗口函数不能出现在 UPDATE SET 中
窗口函数依赖完整的排序与分区上下文才能求值，而 UPDATE 是面向行定位与修改的操作，二者语义冲突。数据库引擎在解析阶段就会拒绝含 OVER() 的表达式——哪怕你套一层子查询，只要最内层 SELECT 用了 ROW_NUMBER() 或 RANK()，就会报错：
-
ERROR: window functions are not allowed in UPDATE（PostgreSQL） -
Windowed functions can only appear in the SELECT or ORDER BY clauses（SQL Server） -
ERROR 1064 (42000): You have an error in your SQL syntax near 'OVER ('（MySQL）
MySQL 8.0+ 正确写法：CTE 预计算 + JOIN 更新
必须把窗口逻辑剥离到 WITH 子句中，再通过主键或唯一字段关联更新。关键不是“能不能用”，而是结构怎么组织：
-
WITH中的 CTE 必须包含原表的唯一标识列（如id），否则JOIN可能一对多或漏匹配 - MySQL 不支持
UPDATE ... FROM，必须写成UPDATE t JOIN cte ON t.id = cte.id SET ... -
WHERE条件要加在JOIN后的最终结果上，比如只更新排名前 3 的记录，得写WHERE r.rn ，而不是在 CTE 里过滤 - 别名必须对齐：
UPDATE orders o JOIN ranked r ON o.id = r.id，但SET里误写成r.rn会报列不存在
示例：
WITH ranked AS ( SELECT id, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM orders ) UPDATE orders o JOIN ranked r ON o.id = r.id SET o.is_primary = (r.rn = 1) WHERE r.rn = 1;
ORDER BY 字段没索引会导致 UPDATE 极慢
窗口函数的 ORDER BY 不是“排完再改”，而是决定计算顺序的依据。如果按无索引字段（如 email）排序，UPDATE 会触发全表排序，锁表时间长、并发差：
- 推荐组合：按业务字段 + 主键保序，例如
ORDER BY priority DESC, id - 重复值风险：时间字段常有重复，务必补一个唯一列（如
id）做第二排序项 - 大表操作前先
EXPLAIN FORMAT=TREE看 CTE 是否走索引；没走就建联合索引 - JOIN 条件若未命中索引，可能升级为表级锁甚至死锁——这是执行计划问题，不是语法问题
真正容易被忽略的是：窗口函数的计算发生在 JOIN 之前，而 UPDATE 的行锁粒度完全取决于 JOIN 条件能否利用索引。别只盯着语法对不对，得看执行路径稳不稳。
