update中不能直接使用窗口函数，必须通过cte或子查询先计算窗口结果，再join原表更新；需确保关联键唯一，优先用row_number()，且各数据库join语法互不兼容。
UPDATE 里不能直接用窗口函数，得绕道 JOIN
SQL 标准不允许在 UPDATE 的 SET 或 WHERE 中直接调用 ROW_NUMBER()、RANK() 等窗口函数——PostgreSQL 报 ERROR: window functions are not allowed in UPDATE，SQL Server 报 Invalid use of aggregate or window function，MySQL 8.0+ 同样拒绝解析。
想按分组排序后更新（比如“每组最新一条标为 is_primary = true”），必须先把窗口计算结果算出来，再通过 JOIN 关联回原表。核心不是“怎么写窗口”，而是“怎么安全落地中间结果”。
- 用
WITHCTE 或子查询生成带分组序号的临时结果，例如：ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn - 中间结果必须含明确关联键（如主键
id或业务唯一键），否则JOIN时可能一对多或多对一，导致一行被更新多次或漏更新 -
ROW_NUMBER()比RANK()更稳妥：避免时间相同时并列第一，导致多条被同时标为true
不同数据库的 JOIN 写法差异很大
CTE 算出序号后，怎么连回原表更新，各数据库语法不兼容，不能照搬。
- PostgreSQL：用
FROM子句，UPDATE orders SET is_primary = (ranked.rn = 1) FROM ranked WHERE orders.id = ranked.id - MySQL：必须写成
UPDATE orders JOIN ranked ON orders.id = ranked.id SET orders.is_primary = (ranked.rn = 1) - SQL Server：要用别名 + 显式
JOIN，UPDATE o SET o.is_primary = (r.rn = 1) FROM orders o INNER JOIN ranked r ON o.id = r.id - 老版本 MySQL（@rownum 方案稳定性差，容易错序，不推荐用于生产
WHERE 条件漏写会导致全表误更新
CTE 和 JOIN 本身不带过滤能力。哪怕你只在 CTE 里写了 PARTITION BY user_id，只要 UPDATE 的 WHERE 没对齐，就可能把不该动的行也更新了。
- 典型错误：CTE 只查了
user_id IN (101, 102)，但UPDATE没加WHERE orders.user_id IN (101, 102)，结果全表is_primary被重置 - 安全做法：在
UPDATE的WHERE里显式限定范围，和 CTE 的过滤条件保持一致 - 务必确保关联字段（如
id）有索引，否则JOIN会触发全表扫描，性能断崖下跌
分组逻辑复杂时，先建临时表更可控
当分组依据涉及多表关联、聚合计算或外部数据源时，硬塞进 CTE 容易让 SQL 过长、难调试、执行计划失控。
- 先建临时表
tmp_ranked，插入带id和rn的结果，对id建索引 - 再用
UPDATE orders JOIN tmp_ranked ON orders.id = tmp_ranked.id SET ... - 临时表可复用、可加注释、可单独
SELECT验证，比嵌套 CTE 更易定位问题 - 如果原表数据量极大（千万级），建议分批处理，例如按
id BETWEEN X AND Y切片，避免单次事务锁太久
