窗口函数不能直接用于update语句，必须先用cte或join结合窗口函数识别目标行，再执行更新，本质是两步操作而非一步完成。
窗口函数不能直接用于 UPDATE 语句
SQL 标准里，UPDATE 不支持直接嵌套窗口函数（如 ROW_NUMBER()、RANK()），哪怕写成子查询或 CTE，多数数据库（PostgreSQL、SQL Server、MySQL 8.0+）也会报错，比如 PostgreSQL 报 ERROR: window functions are not allowed in UPDATE。这不是语法写得不够巧的问题，是执行模型决定的：窗口函数需要完整扫描结果集并排序后才能计算，而 UPDATE 是逐行或按计划修改数据，二者语义冲突。
所以“用窗口函数批量更新重复记录”的真实路径是：先用窗口函数识别目标行，再把结果作为临时依据去驱动更新——本质是两步走，不是一步写个 UPDATE ... OVER(...) 就完事。
用 CTE + 窗口函数定位要保留/删除的重复行
典型场景：表 t_users 中按 email 字段去重，只保留每组中 id 最小的那条，其余标记为 is_duplicate = true 或直接删掉。
PostgreSQL / SQL Server / MySQL 8.0+ 都支持带 WITH 的可更新 CTE（但注意：MySQL 的 CTE 在 UPDATE 中不能直接引用自身，需额外包装）：
WITH dup AS (
SELECT id,
ROW_NUMBER() OVER (PARTITION BY email ORDER BY id) AS rn
FROM t_users
)
UPDATE t_users
SET is_duplicate = true
WHERE id IN (SELECT id FROM dup WHERE rn > 1);
关键点：
-
ROW_NUMBER()比RANK()更适合去重：它不会跳号，确保每组第一个是 1，其余都 >1 -
ORDER BY id决定哪条“保留”，换成created_at DESC就保留最新的一条 - MySQL 8.0+ 若报错
ERROR 1288: The target table t_users of the UPDATE is not updatable，说明 CTE 被优化器判定为不可更新，此时需改用 JOIN 方式（见下一条）
MySQL 8.0+ 必须用 JOIN 替代 CTE 更新
MySQL 对 CTE 的更新限制更严，即使语法合法，也可能因执行计划失败。稳妥做法是把窗口结果作为派生表，和原表 JOIN 更新：
UPDATE t_users u
JOIN (
SELECT id,
ROW_NUMBER() OVER (PARTITION BY email ORDER BY id) AS rn
FROM t_users
) dup ON u.id = dup.id
SET u.is_duplicate = true
WHERE dup.rn > 1;
这个写法在 MySQL 和 PostgreSQL 都能稳定运行。注意：
- 必须显式
JOIN到主表，不能只靠子查询返回id后用IN—— 大表时IN可能触发全表扫描或临时表性能骤降 - 如果要物理删除重复行（不是仅打标），把
SET换成DELETE，但需确认引擎支持（InnoDB 允许，MyISAM 不支持窗口函数） - 字段名重复时（比如子查询也叫
id），MySQL 要求别名明确，否则报ERROR 1052: Column 'id' in field list is ambiguous
UPDATE 前务必加 WHERE 条件和备份验证
批量更新重复记录是最容易误伤生产数据的操作之一。窗口函数逻辑一旦写错（比如漏了 PARTITION BY 或 ORDER BY 错位），可能把本该保留的唯一记录也标为重复。
安全操作顺序：
- 先跑
SELECT查看窗口结果是否符合预期：SELECT email, id, ROW_NUMBER() OVER (PARTITION BY email ORDER BY id) AS rn FROM t_users ORDER BY email, rn;
- 确认无误后，用
UPDATE ... LIMIT 10（MySQL）或UPDATE ... RETURNING *（PostgreSQL）试更新少量数据 - 严禁在没事务包裹、没备份的生产环境直接跑全量
UPDATE - 如果表有外键或触发器，
UPDATE可能触发级联行为，提前检查依赖关系
真正麻烦的从来不是怎么写窗口函数，而是“哪几行该动、哪几行不该动”这个业务逻辑边界没理清——函数只是工具，判断权永远在人手里。
