row_number()必须配合over子句使用，否则报错；它依赖order by（必需）和可选partition by实现全表或分组内唯一连续编号，排序字段需稳定且最好有索引。
ROW_NUMBER() 必须配合 OVER 子句使用，否则直接报错
单独写 ROW_NUMBER() 会触发类似 ERROR: window function ROW_NUMBER requires an OVER clause 的错误。它不是普通函数，而是窗口函数，必须明确指定分区（PARTITION BY）和排序（ORDER BY）逻辑。
最简可用形式是：ROW_NUMBER() OVER (ORDER BY id) —— 表示按 id 升序给所有行连续编号，从 1 开始。
-
ORDER BY是必需的，不写就语法错误； -
PARTITION BY可选，不写即全表为一个分区； -
ORDER BY中的字段最好有索引，否则大表排序开销明显； - 若
ORDER BY字段含 NULL，默认排在最前（PostgreSQL）或最后（MySQL 8.0+），行为不一致，建议显式写ORDER BY col NULLS LAST控制。
分组内编号要用 PARTITION BY，别和 GROUP BY 混用
想按部门分组，每个部门内员工按入职时间编号，就得用 PARTITION BY dept_id。常见误区是以为加个 GROUP BY dept_id 就能实现，但 GROUP BY 会聚合行，而 ROW_NUMBER() 是逐行计算，必须走窗口逻辑。
正确写法：ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY hire_date)
- 每组编号都从 1 重新开始；
-
PARTITION BY支持多个字段，如PARTITION BY dept_id, team_id； - 若误写成
GROUP BY dept_id后再套ROW_NUMBER()，多数数据库会直接报错（“window function is not allowed in GROUP BY”）； - 注意：
PARTITION BY不会改变结果行数，只是重置计数起点。
ORDER BY 相同值时 ROW_NUMBER() 仍强制唯一编号
当 ORDER BY 字段存在重复值（比如多个用户注册时间相同），ROW_NUMBER() 依然会给每行分配不同序号，顺序由底层执行计划决定，不可预测。
如果需要“并列不跳号”，该用 RANK() 或 DENSE_RANK()；如果只想要稳定顺序，必须补上能唯一区分的字段，例如：ORDER BY created_at, id。
-
ROW_NUMBER()的编号永远严格递增、无重复、不跳过； - 依赖单个时间字段排序时，高并发写入可能导致
created_at冲突，补主键是低成本兜底方案； - 某些场景下（如分页取第 N 条），这种不确定性会导致翻页错位，务必提前验证排序字段的唯一性。
性能敏感场景要警惕全表扫描和临时排序
ROW_NUMBER() 在没有合适索引时，可能触发大表全扫描 + 外部排序，尤其当 OVER 子句跨大量数据时。
典型慢查询特征：执行计划里出现 WindowAgg 节点伴随 Sort，且 Sort Method 是 external merge（磁盘排序）。
- 优先在
ORDER BY字段建索引，复合索引可包含PARTITION BY字段（如(dept_id, hire_date)）； - 避免在超大数据集（千万级+）上直接用
ROW_NUMBER()做全局编号，考虑改用应用层流水号或物化视图； - MySQL 8.0 和 PostgreSQL 支持窗口函数下推优化，但 SQLite 直到 3.25 才支持，旧版本需绕行；
- 若仅需前 N 行编号，加上
LIMIT不能减少窗口计算量（窗口函数先执行），应改用子查询 +LIMIT控制输入规模。
ORDER BY 字段的稳定性 —— 看似没问题的查询，在数据量变大或并发写入后突然排序漂移，根源往往就在这里。
