MySQL UPDATE语句语法层禁止窗口函数，因其执行模型限制窗口函数仅可用于SELECT等结果集生成场景；正确做法是用CTE预计算窗口值，再通过JOIN关联更新，且需确保CTE含唯一关联字段。
UPDATE语句语法层直接禁止窗口函数
MySQL 的 UPDATE 解析器在语义检查阶段就拒绝任何含 OVER() 的表达式，无论你写成 SET col = ROW_NUMBER() OVER (...) 还是套一层子查询 —— 只要最内层 SELECT 用了窗口函数，就会报 ERROR 1064 (42000): You have an error in your SQL syntax near 'OVER ('。这不是版本 bug，也不是配置问题，是执行模型层面的硬性限制：窗口函数属于“结果集生成”逻辑（只允许出现在 SELECT、INSERT ... SELECT 等上下文），而 UPDATE 是“行定位 + 修改”操作，二者不可混用。
MySQL 8.0+ 正确写法：CTE 预计算 + JOIN 更新
必须把窗口计算剥离到 WITH 子句中，再通过 JOIN 关联回原表更新。关键点不是“能不能用”，而是“怎么组织语句结构”：
-
WITH中的 CTE 必须包含唯一可关联字段（如主键id），否则JOIN可能一对多或漏匹配 -
UPDATE语句里不能出现FROM（那是 PostgreSQL/SQL Server 的写法），必须显式写UPDATE table1 JOIN cte ON ... -
WHERE条件要加在JOIN后的最终结果上，比如只更新排名前 3 的记录，得写WHERE r.rn ，而不是放在 CTE 里过滤（否则可能丢失关联行）
示例：
WITH ranked AS ( SELECT id, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM orders ) UPDATE orders o JOIN ranked r ON o.id = r.id SET o.is_primary = (r.rn = 1) WHERE r.rn = 1;
MySQL 5.7 及更低版本的现实选择
没有 CTE 和窗口函数，只能靠自连接或变量模拟，但每种都有明显缺陷：
- 用用户变量（如
@rn := @rn + 1）在UPDATE中不可靠：MySQL 8.0+ 已明确不保证变量跨行顺序，5.7 虽能跑通，但并发执行时序不确定，无法用于生产环境 - 自连接模拟
LAG()或排名，需多层NOT EXISTS排除中间行，SQL 复杂且易错；大数据量下容易触发Using temporary; Using filesort，必须给(user_id, created_at)加联合索引 - 临时表方案（
CREATE TEMPORARY TABLE ... SELECT ...）可行但非原子操作：先建表、再更新、再删表，中间出错需手动清理，且无法回滚
最容易被忽略的细节
即使你按 CTE + JOIN 写对了，仍可能踩坑：CTE 别名和 UPDATE 表别名不一致会导致列解析失败（例如 CTE 里叫 r，UPDATE 里却用 o 做 JOIN，但 SET 子句里误写成 r.rn）；另外，如果原表没主键或唯一键，JOIN 可能产生重复匹配，导致部分行被多次更新或跳过——这种错误不会报错，只会静默写坏数据。
