ROW_NUMBER() 不能生成全局唯一自增序列，因其仅对当前查询结果逻辑编号、不持久、不跨查询、需强制指定ORDER BY且序号随数据变动而变化；适合导出报表时按确定性排序键临时编号，持久化需结合CTE或UPDATE，真正发号应使用序列对象或自增主键。
ROW_NUMBER() 不能直接生成全局唯一自增序列
直接在任意查询中写 ROW_NUMBER() OVER () 会报错 —— 窗口函数必须指定排序依据，OVER () 语法非法。更重要的是，即使加了 ORDER BY，它也只是对当前结果集做逻辑编号，不持久、不跨查询、不保证全局递增（比如两次执行可能因数据变动导致相同行拿到不同序号）。
所以别指望靠一次 ROW_NUMBER() 调用就“生成”一个类似 AUTO_INCREMENT 的稳定序列。它本质是计算型函数，不是序列生成器。
用 ROW_NUMBER() 模拟序列的典型场景：导出/报表时临时编号
最常见且安全的用法，是在导出全表或分页结果时，给每行加一个从 1 开始的连续序号，方便阅读或对接下游系统。这时关键是选一个**确定性排序键**，避免结果抖动：
- 优先用主键或带索引的唯一字段，如
ROW_NUMBER() OVER (ORDER BY id) - 若无合适业务字段，可用
ORDER BY ctid（PostgreSQL）或ORDER BY %%physloc%%（SQL Server，不推荐生产用）——但这类物理位置排序不可移植，且下次 vacuum 或 rebuild 后会变 - 绝对不要用
ORDER BY RAND()或无意义常量（如ORDER BY 1），会导致每次执行序号乱序
示例（PostgreSQL）：
SELECT ROW_NUMBER() OVER (ORDER BY created_at, id) AS seq, name, email FROM users;
想持久化？得配合 INSERT + CTE 或物化视图
如果真需要把编号存进表里（比如迁移旧数据时补序号列），不能只靠查询，得落地。常见做法是用 CTE + INSERT ... SELECT 或 UPDATE：
- 先确保目标表有可更新的唯一标识（如主键
id） - 用
ROW_NUMBER() OVER (ORDER BY ...)计算序号，再通过主键关联回原表 - 注意：若排序字段有重复值，
ROW_NUMBER()仍会强制分配不同序号，但顺序不确定（需加二级排序兜底）
示例（为已有表添加 seq_no 列并填充）：
ALTER TABLE orders ADD COLUMN seq_no BIGINT;<br>WITH numbered AS (<br> SELECT id, ROW_NUMBER() OVER (ORDER BY order_date, id) AS rn<br> FROM orders<br>)<br>UPDATE orders o<br>SET seq_no = n.rn<br>FROM numbered n<br>WHERE o.id = n.id;
替代方案比 ROW_NUMBER() 更适合“生成序列”的场景
如果你实际要的是“每次插入自动获得下一个整数”，那窗口函数不是正解。应优先考虑：
- 数据库原生序列对象：PostgreSQL 的
CREATE SEQUENCE+NEXTVAL()，MySQL 8.0+ 的CREATE SEQUENCE - 自增主键：MySQL 的
AUTO_INCREMENT，PostgreSQL 的SERIAL或GENERATED ALWAYS AS IDENTITY - 应用层发号器（如 Snowflake、Redis INCR）——适合分布式环境
ROW_NUMBER() 是事后计算，其他方案才是事前分配。混用容易导致幻读、重复或跳号。
真正难的不是写对语法，而是想清楚：你到底要“标号”还是“发号”？前者用 ROW_NUMBER() 没问题，后者硬套它，迟早掉坑里。
