UPDATE语句的SET子句中不能直接使用窗口函数，这是MySQL 8.0的语法硬限制；必须通过CTE先计算结果再JOIN更新，且需确保一对一匹配、排序稳定、事务验证。
UPDATE 语句的 SET 子句里**不能直接写窗口函数**——这不是配置问题，是 MySQL 8.0 的语法硬限制。想用 ROW_NUMBER()、SUM() OVER() 等做更新逻辑，必须绕道 CTE + JOIN。
为什么 UPDATE SET 里直接写 ROW_NUMBER() 会报 ERROR 1064
MySQL 解析器在语法检查阶段就拒绝窗口函数出现在 UPDATE ... SET 中。哪怕你加了 WHERE、主键索引全在、子查询套了一层，照样失败。错误信息通常是：ERROR 1064 (42000): You have an error in your SQL syntax。这不是运行时错误，是根本没进执行阶段。
正确路径：用 WITH 定义 CTE，再 JOIN 更新
这是唯一生产可用的方式，核心是两步：先算出带序号/累计值的结果集，再通过主键一对一绑定回原表。
-
WITH必须包含原表的唯一标识字段（如id），且该字段要参与JOIN条件 -
JOIN条件必须严格一对一，否则可能误更新多行或零行（比如ON o.id = r.id，不能漏） - 别模仿 PostgreSQL 写
UPDATE ... FROM，MySQL 不认这个语法 - 示例：
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;
ORDER BY 字段选错会导致结果不可控
窗口函数里的 ORDER BY 不是“排完再取”，而是定义计算顺序的依据——它直接决定 ROW_NUMBER()、LAG()、累计求和等输出。几个关键点：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 用无索引字段（如
email）做排序，会触发全表排序，UPDATE可能超时 -
created_at有重复值时，ROW_NUMBER()结果不稳定，必须补一个唯一列（如id）作为第二排序项 - 业务权重排序（如
PRIORITY DESC, updated_at）要确认PRIORITY有索引，否则性能崩盘
上线前不验证等于裸奔
窗口函数生成的序号只在当前查询中有效，没法预览就直接执行，线上表极易翻车。
- 务必用事务包裹：
START TRANSACTION - 先用
SELECT模拟效果，例如：
WITH ranked AS ( SELECT id, ROW_NUMBER() OVER (ORDER BY created_at, id) AS new_seq FROM orders WHERE status = 'pending' ) SELECT o.id, o.seq, r.new_seq FROM orders o JOIN ranked r ON o.id = r.id;
确认映射关系和数值范围都符合预期，再执行 UPDATE。最容易被忽略的是：CTE 输出的行数是否和原表匹配——少一行就漏更新，多一行就报错或静默失败。
