sql标准禁止update中直接使用group by或窗口函数；正确做法是用cte或子查询封装窗口计算结果，再通过join关联原表更新，且需注意排序稳定性、索引优化与where位置。
为什么直接用 GROUP BY + UPDATE 会报错
SQL 标准不允许在 UPDATE 语句里直接写 GROUP BY 或 HAVING，MySQL、PostgreSQL、SQL Server 全部拒绝这种写法。你如果试过 UPDATE t1 SET x = (SELECT COUNT(*) FROM t2 GROUP BY y)，大概率会遇到 Subquery returns more than 1 row 或语法错误——因为聚合子查询没和主表对齐，数据库不知道该把哪一行结果赋给哪一行更新目标。
窗口函数不是用来直接 UPDATE 的，而是用来“准备数据”
窗口函数本身不能出现在 SET 右侧（比如 SET status = ROW_NUMBER() OVER (...) 是非法的），它的作用是生成带序号/排名/累计值的中间结果，再通过 JOIN 或 FROM 关联到原表完成更新。关键路径是：窗口计算 → CTE 或子查询封装 → 关联主表 → 更新。
-
ROW_NUMBER()最适合取每组最新/最旧记录，但必须配PARTITION BY+ 明确的ORDER BY，否则排序不稳定 - 如果只想要分组统计值（如每用户订单数），用
COUNT() OVER (PARTITION BY user_id)比嵌套子查询更简洁，但要注意它会在原表每行都重复输出相同值，所以后续仍需去重或限制更新范围 - 避免在窗口中对高基数列（如
id）做PARTITION BY：SQL Server 和 PostgreSQL 会强制排序，8000万行就可能撑爆 TempDB
MySQL 8.0+ / PostgreSQL / SQL Server 通用写法：CTE + UPDATE FROM / JOIN
以“标记每个用户最新订单为 is_primary = true”为例，三者核心逻辑一致，只是语法微调：
PostgreSQL 写法：
WITH ranked AS (
SELECT id,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC, id DESC) AS rn
FROM orders
WHERE status = 'completed' -- ✅ 过滤必须放 CTE 内，控制参与排序的数据
)
UPDATE orders o
SET is_primary = (r.rn = 1)
FROM ranked r
WHERE o.id = r.id;
MySQL 写法：
UPDATE orders o
JOIN (
SELECT id,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC, id DESC) AS rn
FROM orders
WHERE status = 'completed'
) r ON o.id = r.id
SET o.is_primary = (r.rn = 1);
- CTE 或子查询里的
WHERE是安全边界：它决定了哪些行参与窗口编号，漏写会导致误标 -
UPDATE后的WHERE只保留关联条件（如o.id = r.id），别再加业务过滤——否则可能让未匹配行被设为 NULL - 务必在
ORDER BY中补充次级字段（如id DESC），否则时间相同时ROW_NUMBER()分配顺序不可控
容易被忽略的性能雷区
窗口函数不是银弹。当你在 OVER 子句里同时写 PARTITION BY 和 ORDER BY，数据库必须执行一次全局排序，即使你只是想取每组第一行。如果 PARTITION BY 列没有索引，或者数据量超千万，这个排序就是瓶颈。
- 查执行计划，重点看有没有
Sort运算符且Estimated Number of Rows极大——那是性能杀手 - 如果只是取最新一条，且
user_id + created_at有联合索引，用MAX(created_at)子查询+关联反而更快 -
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW这类帧定义会阻止并行计算，大数据量下比简单PARTITION BY更慢
