窗口函数不能直接用于UPDATE语句的SET子句，因所有主流数据库均禁止在DML赋值中使用ROW_NUMBER()、RANK()等依赖上下文的窗口表达式；正确做法是先用CTE或临时表预计算结果，再通过JOIN更新目标表。
如果你尝试在 UPDATE 语句的 SET 子句里直接嵌入 ROW_NUMBER() 或 RANK() 这类窗口函数，结果大概率是碰壁。无论是 MySQL、PostgreSQL、SQL Server 还是 Oracle，主流数据库的设计都明确禁止这种操作。这并非语法上的疏忽，而是源于一个根本的设计限制：更新操作要求为每一行提供一个确定且可重复的单值结果，而窗口函数的计算高度依赖于其所在的分区与排序上下文，一旦脱离原始的查询作用域，便无法独立求值。
为什么不能在 UPDATE SET 中直接用 ROW_NUMBER()？
很多开发者都曾踩过这个坑，写出类似下面这样的语句，然后被数据库无情驳回：
UPDATE orders SET seq_no = ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY created_at) WHERE status = 'shipped';
执行时，你会看到各种熟悉的错误提示：
ERROR: window functions are not allowed in UPDATE（PostgreSQL）Invalid use of a window function（SQL Server）This version of MySQL doesn't yet support 'window function in UPDATE'（即便是 MySQL 8.0+ 版本也依然不支持）
这里有几个关键点需要厘清：
- 窗口函数的标准使用场景被严格限定在
SELECT、ORDER BY或HA VING子句中，它不能直接作为 DML（数据操作语言）语句中的赋值表达式。 - 即使你试图用子查询将其包裹起来，比如写成
UPDATE ... SET x = (subquery)的形式，只要这个子查询内部包含了窗口函数，绝大多数数据库引擎依然会拒绝执行（MySQL 在这方面尤其严格）。 - 当然，规则总有极少数例外。例如，Oracle 允许在
MERGE语句的USING子句中使用窗口函数来生成中间结果集，但最终在UPDATE部分进行赋值时，引用的仍然是普通的列。
替代方案：用 CTE 预计算 + JOIN 更新
那么，正确的路径是什么？其实思路很清晰：把需要窗口函数计算的逻辑“提前算好”，将结果（连同每行的唯一标识）存入一个临时的中间结果集，然后再通过 JOIN 关联回目标表进行更新。这是目前跨数据库最通用、最稳妥的解决方案。
举个例子，假设我们需要给每位客户最新的 3 条已发货订单打上 is_top3 = true 的标记：
WITH ranked AS (
SELECT id,
ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY created_at DESC) AS rn
FROM orders
WHERE status = 'shipped'
)
UPDATE orders o
SET is_top3 = true
FROM ranked r
WHERE o.id = r.id AND r.rn <= 3;
这里有几个语法细节需要注意：
- PostgreSQL 支持上述这种
UPDATE ... FROM的语法；而在 SQL Server 中，对应的写法通常是UPDATE o SET ... FROM orders o INNER JOIN ranked r ON o.id = r.id。 - MySQL 不支持
UPDATE ... FROM语法，需要改用多表JOIN的形式：UPDATE orders o JOIN ranked r ON o.id = r.id SET o.is_top3 = true WHERE r.rn <= 3。 - 另外，所使用的 CTE（公共表表达式）必须是一个逻辑上可更新的结果集。如果 CTE 中包含了聚合、去重或某些不可逆的转换，部分数据库可能会拒绝执行后续的关联更新操作。
当需要按窗口排名更新数值字段时，小心 NULL 和重复排序
实际应用中，情况往往更复杂。比如，你想将订单按金额降序排列，然后给排名前 10% 的订单设置 priority = 1，其余设为 0。这时，至少有两个陷阱需要警惕：
- 当使用
PERCENT_RANK()或NTILE(10)这类函数时，如果数据中存在NULL值，其行为可能不一致。例如，MySQL 和 PostgreSQL（默认情况下）会跳过NULL值参与排序。如果没有显式地通过WHERE amount IS NOT NULL进行过滤，就可能导致本应被标记的记录被意外遗漏。 - 另一个常见问题是排序的稳定性。如果
ORDER BY的字段（如amount）存在大量重复值，ROW_NUMBER()在相同值之间的序号分配是随机的（除非指定了额外的排序依据）。这会导致两次相同的查询可能产生不同的结果。为了保证结果稳定可重现，务必在ORDER BY子句中加入一个唯一列（如主键id）作为兜底，例如：ORDER BY amount DESC, id ASC。 - 最后，数据类型转换也可能暗藏风险。如果目标字段是
TINYINT或BOOLEAN类型，确保SET priority = 1这样的赋值不会因为隐式类型转换而失败，尤其是在 PostgreSQL 中，它对布尔类型的赋值更为敏感。
别试图绕过限制：临时表 or application 层处理？
面对限制，有人可能会想其他“绕路”的办法。比如，先创建一个临时表：CREATE TEMP TABLE tmp_ranked AS SELECT ..., ROW_NUMBER() ...，然后再执行 UPDATE JOIN tmp_ranked。从逻辑上看，这确实可行。但问题在于，它引入了额外的磁盘 I/O 和事务日志开销。对于数据量巨大的表（比如千万级），这种方法很可能比使用 CTE 更慢，因为现代数据库引擎对 CTE 往往有物化优化，而显式创建的临时表未必能享受到同等的优化待遇。
更危险的做法，是把窗口计算的逻辑完全搬到应用层。想象一下：用 Python 或 Ja va 从数据库里拉出全部 30 万行数据，在内存中用 pandas 或类似库进行排名计算，然后再分批发起 30 万条 UPDATE 语句写回数据库。这种做法不仅会带来巨大的网络传输开销，还会显著增加数据库的锁等待和超时风险，更无法保证整个操作的原子性，一旦中途失败，数据状态将难以清理。
话说回来，真正值得警惕的，或许不是“如何写窗口函数”，而是“这个需求是否真的必须使用窗口函数”。很多时候，用 EXISTS 子查询，或者分步的 UPDATE 配合 LIMIT（在 MySQL 中）就能满足业务需求。这些方法往往更直观，也更容易进行审计和回滚，何乐而不为呢？
