UPDATE语句不能直接使用窗口函数，因窗口函数依赖查询结果集而UPDATE操作底层行；必须通过CTE或子查询先计算窗口值，再关联更新，且需严格验证JOIN条件以防漏更、误更或全表覆盖。
UPDATE 语句不能直接引用窗口函数
SQL 标准和主流数据库（PostgreSQL、SQL Server、Oracle）都不允许在 UPDATE 的 SET 或 WHERE 子句中直接写 ROW_NUMBER()、RANK() 等窗口函数。你如果试过类似 UPDATE t SET flag = ROW_NUMBER() OVER (ORDER BY id)，会立刻收到语法错误，比如 PostgreSQL 报 ERROR: window functions are not allowed in UPDATE。
根本原因是：窗口函数依赖于查询结果集的逻辑分组与排序，而 UPDATE 本身不产生可被窗口函数作用的“结果集”——它操作的是底层行，不是查询视图。
用 CTE + UPDATE FROM（PostgreSQL / SQL Server）或子查询（MySQL 8.0+）绕过限制
实际可行的路只有一条：先用 CTE 或派生表把窗口函数算好，再把它当作“源数据”去驱动 UPDATE。不同数据库写法略有差异，但思路一致——把窗口计算和更新拆成两步，靠主键/唯一键关联。
- PostgreSQL：支持
UPDATE ... FROM，最简洁 - SQL Server：用
UPDATE ... FROM或 CTE +UPDATE cte_name - MySQL 8.0+：只能用 JOIN 形式的子查询（因不支持
UPDATE ... FROM的多表语法）
例如，在 PostgreSQL 中给每个用户按登录时间打序号并更新到 user_rank 字段：
WITH ranked AS ( SELECT id, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_time) AS rn FROM login_log ) UPDATE users u SET user_rank = r.rn FROM ranked r WHERE u.id = r.id;
注意 WHERE 条件必须精确匹配，否则 UPDATE 会漏行或误更新
窗口函数计算出的中间结果（如 CTE 中的 ranked）通常不含完整表字段，只含用于关联的键（如 id）和要写的值（如 rn）。一旦 WHERE 关联条件写错，后果很直接：
- 漏更新：关联不上 → 对应行
SET不生效，字段保持 NULL 或旧值 - 重复更新：CTE 中一行对应主表多行 → 同一记录被多次 SET，最终值取决于执行顺序（不可靠）
- 全表误更新：忘记
WHERE或条件恒真 → 整张表被设成同一个窗口值
强烈建议在执行前先用 SELECT 验证关联效果：
WITH ranked AS ( SELECT user_id, ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rank_in_dept FROM employees ) SELECT e.name, e.salary, r.rank_in_dept FROM employees e JOIN ranked r ON e.user_id = r.user_id;
MySQL 8.0+ 必须用 JOIN 子查询，且不能直接 UPDATE 原表别名
MySQL 对窗口函数支持较晚，且语法更受限：它不允许在 UPDATE 中直接引用 CTE（报错 Unknown table 'cte_name' in MULTI-UPDATE），也不允许 UPDATE t1 JOIN t2 中 t1 是原表别名（会提示 You can't specify target table for update in FROM clause）。正确解法是把 CTE 包一层派生表，并确保子查询不直接引用被更新的表。
安全写法示例（给订单按用户分组编号）：
UPDATE orders o JOIN ( SELECT order_id, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at) AS seq FROM orders ) AS ranked ON o.order_id = ranked.order_id SET o.seq_in_user = ranked.seq;
这里关键点是：子查询用了 FROM orders，但它在 JOIN 右侧，MySQL 允许；而左侧 UPDATE orders o 是独立目标，不违反限制。
窗口函数本身没问题，难的是让它安全落地——每一步关联都要可验证，每一处别名都要避开数据库的语法禁区。稍不注意，不是报错就是静默错更新。
