窗口函数不能直接用于UPDATE语句的SET子句，因所有主流数据库均禁止在DML赋值中使用ROW_NUMBER()、RANK()等依赖上下文的窗口表达式；正确做法是先用CTE或临时表预计算结果，再通过JOIN更新目标表。
窗口函数 本身不能直接用于 UPDATE 语句的 SET 子句中——所有主流数据库（MySQL、PostgreSQL、SQL Server、Oracle）都不支持在 UPDATE 里写 ROW_NUMBER()、RANK() 或 LAG() 这类表达式作为赋值来源。这不是语法疏漏，而是设计限制：更新操作要求每行有确定、可重复的单值结果，而窗口函数依赖分区与排序上下文，无法脱离查询作用域独立求值。
为什么不能在 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或HAVING子句中，不能作为 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
- 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 - CTE 必须是可更新的逻辑结果（即不能含聚合、去重、不可逆转换），否则某些数据库会拒绝关联更新
当需要按窗口排名更新数值字段时，小心 NULL 和重复排序
比如想把订单按金额降序排，给前 10% 订单加 priority = 1，其余为 0。注意两个陷阱：
-
PERCENT_RANK()或NTILE(10)在NULL值存在时行为不一致：MySQL 会跳过NULL参与排序，PostgreSQL 默认也如此，但若未显式WHERE amount IS NOT NULL，可能漏掉本应被标记的记录 - 相同
amount值会导致ROW_NUMBER()随机分配序号（无ORDER BY ... COLLATE或附加字段时），两次执行结果可能不一致 —— 若业务要求稳定，务必在ORDER BY中加入主键等唯一列兜底，如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/Java 读出全量再分批更新）：30 万行数据拉到内存做 pandas.rank() 再发 30 万条 UPDATE，网络开销、锁等待、超时风险陡增，且无法保证原子性。
真正该警惕的，不是“怎么写窗口函数”，而是“这个需求是否真需要窗口函数”——很多时候用 EXISTS 子查询或分步 UPDATE + LIMIT（MySQL）就能满足，还更易审计、回滚。
