窗口函数不能直接用于UPDATE语句，必须通过CTE或子查询先计算窗口结果（如ROW_NUMBER()），再JOIN或IN关联原表更新；需确保PARTITION BY和ORDER BY字段准确、有索引，并用SELECT预先验证逻辑。
窗口函数不能直接用于 UPDATE 语句
SQL 标准里，UPDATE 不支持直接嵌套 ROW_NUMBER()、RANK() 这类窗口函数——多数数据库（PostgreSQL、SQL Server、MySQL 8.0+）都会报错，比如 PostgreSQL 报 ERROR: window functions are not allowed in UPDATE。这不是语法写错了，是语言设计限制：窗口函数必须在查询执行的“结果集生成阶段”使用，而 UPDATE 的目标行是在更早阶段锁定的。
想用窗口函数逻辑去更新重复数据，得绕道走：先用窗口函数识别出要保留/删除/标记的行，再把结果作为子查询或 CTE 提供给 UPDATE。
用 CTE + 窗口函数定位重复行并更新
典型场景：表 users 中有多个 email 相同的记录，只保留 id 最小的那条，其余设为 is_duplicate = true 或更新 status 字段。
- 必须用 CTE（或子查询）先算出每组重复里的排序，比如：
ROW_NUMBER() OVER (PARTITION BY email ORDER BY id) - CTE 中不能写
UPDATE，但可以给每一行打上标记（如rn），然后在外层UPDATE中引用该标记 - MySQL 8.0+、PostgreSQL、SQL Server 都支持这种写法；SQLite 不支持 CTE 用于
UPDATE的左值，需改用 JOIN 方式
PostgreSQL 示例：
WITH ranked AS (
SELECT id,
ROW_NUMBER() OVER (PARTITION BY email ORDER BY id) AS rn
FROM users
)
UPDATE users
SET status = 'duplicate'
WHERE id IN (SELECT id FROM ranked WHERE rn > 1);
UPDATE 时 JOIN 窗口结果（兼容性更强）
某些数据库（如旧版 MySQL）不支持 CTE 在 UPDATE 中被直接引用，这时用 JOIN 更稳妥。本质是把窗口结果当临时表用，和原表关联更新。
- 注意别漏掉
ON条件，否则可能误更新整张表 - MySQL 要求必须给子查询起别名（哪怕只是
AS t），否则报错Every derived table must have its own alias - 性能上，如果重复组很大，
JOIN可能比 CTE 多一次全表扫描，加索引（如(email, id)）能显著提速
MySQL 示例：
UPDATE users u
JOIN (
SELECT id,
ROW_NUMBER() OVER (PARTITION BY email ORDER BY id) AS rn
FROM users
) ranked ON u.id = ranked.id
SET u.status = 'duplicate'
WHERE ranked.rn > 1;
避免误删或漏更新的三个关键点
实际跑这类语句最容易翻车的地方不在语法，而在数据逻辑判断上：
-
PARTITION BY列选错：比如用name而不是email去分组，导致本不该合并的记录被标记 -
ORDER BY不明确：如果ORDER BY字段有 NULL 或重复值（如都为 0），ROW_NUMBER()结果不稳定，每次执行可能保留不同行 - 没加
WHERE限制范围：测试时忘记加AND email IS NOT NULL，结果把空邮箱也当重复处理了
上线前务必用 SELECT 先验证窗口结果，例如：SELECT *, ROW_NUMBER() OVER (PARTITION BY email ORDER BY id) FROM users WHERE email IS NOT NULL LIMIT 10 —— 看清楚哪几行会被更新，再动手。
