ROW_NUMBER() OVER (ORDER BY col1, col2) 可生成严格唯一的递增ID，即使col1和col2组合相同也按出现顺序编号；必须指定ORDER BY，支持表达式但需确定性，配合PARTITION BY可实现分组内独立编号。
ORDER BY 多列时，ROW_NUMBER() 怎么写才不重复？
直接用 ROW_NUMBER() OVER (ORDER BY col1, col2) 是最简方式，但要注意：只要 col1 和 col2 的组合值完全相同，ID 就会按出现顺序递增（不是“重复”，而是严格唯一），这正是你想要的“唯一ID”。很多人误以为会报错或跳号，其实不会。
常见错误是漏掉 ORDER BY 子句——窗口函数必须有排序依据，否则语法报错：Window function 'row_number' requires an ORDER BY clause。
- 排序列顺序影响 ID 分配顺序，比如
ORDER BY status, created_at和ORDER BY created_at, status生成的 ID 序列完全不同 - NULL 值默认排在最前（PostgreSQL/SQL Server）或最后（MySQL 8.0+），若需统一行为，显式写
ORDER BY col1 NULLS LAST（仅 PostgreSQL/Oracle 支持） - 避免在排序中混用 ASC/DESC 不一致的列，容易导致逻辑难追溯，例如
ORDER BY a ASC, b DESC没问题，但团队协作时最好加注释说明意图
需要稳定可复现的 ID？得看是否加 PARTITION BY
如果你的“多列排序”其实是分组内排序（比如每个 category 内按 price 排名），就必须加 PARTITION BY category。否则所有行参与全局排序，ID 是整个结果集唯一的连续整数。
典型场景：导出报表时给每类商品独立编号，而不是全表统编。这时 ID 会从 1 重新开始，且只在同 category 内保证顺序。
-
PARTITION BY列不必出现在ORDER BY中，但通常有关联性；例如按category分组、再按sales排序，就写PARTITION BY category ORDER BY sales DESC - 分区键含 NULL 时，所有 NULL 值会被归为同一组（多数数据库行为一致），若业务上 NULL 表示“未知类别”，这点必须提前确认是否合理
- 性能上，
PARTITION BY会增加计算开销，尤其当分区过多（如百万级不同user_id）时，建议先过滤再开窗，而非全量扫表后分区
ROW_NUMBER() vs RANK() vs DENSE_RANK()：选哪个取决于“重复怎么算”
三者都依赖相同 ORDER BY，区别只在遇到相等排序值时的编号策略：
-
ROW_NUMBER()：强制唯一，哪怕col1=col2完全一样，也按物理顺序（或优化器决定的扫描顺序）给不同 ID —— 这是你“赋予唯一ID”的刚需 -
RANK()：相同值共享一个排名，后续跳号，比如 [1,1,3]；适合“并列第1名，下一位是第3名”的语义 -
DENSE_RANK()：相同值共享排名，后续不跳号，比如 [1,1,2]；适合榜单类展示
所以只要目标是“每行一个不重复整数 ID”，只用 ROW_NUMBER()，其他两个本质是“排名”，不是“ID”。
ORDER BY 里能用表达式或函数吗？可以，但注意确定性
可以写 ORDER BY UPPER(name), LENGTH(description) 或 ORDER BY COALESCE(updated_at, created_at)，但必须确保表达式结果是确定性的（same input → same output）。非确定函数会导致 ID 每次执行不一致。
- 禁止使用
NOW()、RANDOM()、UUID()等运行期随机/时间敏感函数作为排序依据，否则ROW_NUMBER()结果不可复现 - 自定义函数如果标记为
VOLATILE（PostgreSQL）或未声明DETERMINISTIC（MySQL），同样危险；上线前务必查函数属性 - 字符串排序注意 collation，比如
ORDER BY name COLLATE utf8mb4_0900_as_cs在大小写敏感场景下会影响顺序，进而影响 ID 分配
真正难处理的是排序键本身存在隐式类型转换（比如把数字字符串 '10' 和 '2' 当文本排成 '10','2'），这种 bug 往往要到下游系统比对 ID 顺序异常时才暴露。
