MySQL 8.0 中 UPDATE 不支持直接使用窗口函数，必须通过 CTE 先计算再 JOIN 更新；需确保 ORDER BY 字段有索引、JOIN 条件唯一，并用事务验证后再执行。
MySQL 8.0 中无法直接在 UPDATE 语句里写 ROW_NUMBER() 或 SUM() OVER()，但可以通过 CTE + JOIN 组合实现原子、可预测的批量更新——这是唯一推荐的生产级做法。
UPDATE 不能直接用窗口函数，必须用 CTE 中转
你写 UPDATE t SET col = ROW_NUMBER() OVER (ORDER BY id) 会报错 ERROR 1064。MySQL 不允许窗口函数出现在 UPDATE 的 SET 子句中。窗口函数只能在 SELECT、INSERT ... SELECT 或 CTE 内部使用。
- CTE 是必须环节：先用
WITH cte AS (SELECT id, ROW_NUMBER() OVER (ORDER BY created_at) AS new_seq FROM orders)算出序号 - 再用
UPDATE orders JOIN cte ON orders.id = cte.id SET orders.seq = cte.new_seq回写，确保一对一匹配 - 如果漏掉
JOIN条件或关联字段不唯一，可能更新多行或零行——尤其当表无主键或存在重复id时
ORDER BY 字段决定序号逻辑，选错就全乱
窗口函数的 ORDER BY 不是“排序结果”，而是定义计算顺序的依据。它直接影响 ROW_NUMBER()、LAG()、累计求和等所有依赖顺序的逻辑。
- 按时间排序：
ROW_NUMBER() OVER (ORDER BY created_at, id)—— 防止时间相同时序号不确定 - 按业务权重排序：
ROW_NUMBER() OVER (ORDER BY priority DESC, updated_at)—— 高优先级排前面 - 千万别用无索引字段（如
email）做ORDER BY，会导致全表排序，UPDATE 变得极慢 - 若需稳定排序但字段本身有重复，务必补一个唯一列（如主键
id）做第二排序项
用事务包裹，先查后更，避免误操作
窗口函数生成的序号只在当前查询中有效，无法预览就直接执行。线上表千万不能跳过验证步骤。
- 先开事务：
START TRANSACTION; - 用
SELECT模拟更新效果：WITH cte AS (SELECT id, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM nl_emails) SELECT id, row_num AS old, rn AS new FROM nl_emails JOIN cte USING(id) LIMIT 10; - 确认无误后再跑
UPDATE，出错可立刻ROLLBACK; - 特别注意：如果表数据量大（>100 万行），
EXPLAIN FORMAT=TREE看 CTE 是否走索引；没走的话，ORDER BY字段必须建索引
真正容易被忽略的点是：窗口函数的计算发生在 JOIN 之前，而 UPDATE 的行锁粒度取决于 JOIN 条件是否能命中索引。用非主键字段 JOIN，可能触发表级锁或死锁——不是语法问题，是执行计划层面的风险。
