MySQL 8.0 不支持在 UPDATE 的 SET 子句中直接使用窗口函数，必须通过 CTE + JOIN 实现更新；窗口函数仅允许出现在 SELECT、INSERT ... SELECT 或 CTE 中，且 JOIN 必须基于唯一字段一对一匹配，否则导致数据错误。
MySQL 8.0 中不能在 UPDATE 语句的 SET 子句里直接写 ROW_NUMBER()、SUM() OVER() 等窗口函数——这是语法硬限制，不是配置或版本问题。
为什么 UPDATE 里直接用窗口函数会报错
你写 UPDATE t SET seq = ROW_NUMBER() OVER (ORDER BY id)，MySQL 会立刻抛出 ERROR 1064。因为窗口函数只被允许出现在 SELECT、INSERT ... SELECT 或 CTE 内部；UPDATE 的 SET 部分不支持任何窗口表达式。
- 这不是 bug，是 SQL 标准与 MySQL 实现共同决定的解析阶段限制
- 哪怕加了
WHERE、用了唯一索引，也无效——语法层就拒绝解析 - 试图用子查询包裹（如
(SELECT ROW_NUMBER() ...) AS rn）同样失败，因为子查询里也不能出现窗口函数用于赋值上下文
必须用 CTE + JOIN 实现更新
唯一可靠、可验证、生产可用的路径是：先用 WITH 定义 CTE 计算窗口结果，再通过 JOIN 关联原表更新。
- CTE 必须包含能唯一匹配原表的字段（通常是主键
id） -
JOIN条件必须严格一对一，否则可能误更新多行或零行 - 示例写法：
WITH ranked AS ( SELECT id, ROW_NUMBER() OVER (ORDER BY created_at, id) AS new_seq FROM orders ) UPDATE orders o JOIN ranked r ON o.id = r.id SET o.seq = r.new_seq;
- 别用
UPDATE ... FROM（PostgreSQL/SQL Server 风格），MySQL 不识别该语法 - 别省略
JOIN条件中的ON子句，否则变成笛卡尔积，后果严重
ORDER BY 字段选错会导致序号逻辑崩溃
窗口函数里的 ORDER BY 不是“把结果排好给你看”，而是定义计算顺序的依据——它直接决定 ROW_NUMBER()、LAG()、累计求和等所有依赖顺序的输出。
- 用无索引字段（如
email）做ORDER BY，会导致全表排序，UPDATE执行极慢甚至超时 - 时间字段（如
created_at）若存在重复值，ROW_NUMBER()结果不稳定——必须补一个唯一列（如id）作为第二排序项 - 业务权重排序（如
PRIORITY DESC, updated_at）要确认PRIORITY字段有索引，否则性能不可控
上线前必须验证，跳过这步等于裸奔
窗口函数生成的序号只在当前查询中有效，无法预览就直接执行，线上表极易翻车。
- 务必用事务包裹：
START TRANSACTION; - 先用
SELECT模拟效果：
WITH ranked AS ( SELECT id, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM nl_emails ) SELECT e.id, e.seq AS old_seq, r.rn AS new_seq FROM nl_emails e JOIN ranked r ON e.id = r.id;
- 检查
old_seq和new_seq是否符合预期，行数是否一致 - 确认
JOIN后没丢失或重复行（COUNT(*)对比原表） - 验证通过后才执行
UPDATE，最后COMMIT；出错则ROLLBACK
最易被忽略的是：CTE 输出与原表关联字段的唯一性——如果原表没有主键，或 JOIN 字段存在 NULL / 重复值，整个更新逻辑就失去确定性。这不是性能问题，是数据正确性红线。
