ROW_NUMBER()必须配合OVER子句使用，否则报错；其基本形式为ROW_NUMBER() OVER (ORDER BY column)，分组需加PARTITION BY，且ORDER BY不可省略以确保排序稳定性和编号唯一性。
ROW_NUMBER() 必须配合 OVER 子句使用，否则直接报错
单独写 ROW_NUMBER() 会触发类似 ERROR: window function ROW_NUMBER requires an OVER clause 的错误。它不是普通函数，而是窗口函数，必须明确指定排序逻辑和（可选）分组逻辑。
最简可用形式是：ROW_NUMBER() OVER (ORDER BY some_column)。注意：ORDER BY 在 OVER 里是必需的——哪怕你只是想按插入顺序编号，也得找一个能稳定排序的列（比如主键或时间戳），不能省略。
- 如果表没有天然有序字段，又确实需要“物理顺序”，可先用
ctid（PostgreSQL）或%%physloc%%（SQL Server，不推荐）临时辅助，但这类值不稳定，不可用于业务逻辑 - MySQL 8.0+ 支持
ROW_NUMBER()，但 5.7 及更早版本不支持，需用变量模拟（易出错，不建议） - Oracle 和 SQL Server 从较早版本就支持，语法一致
给分组内数据单独编号要用 PARTITION BY
当需要“每个部门内员工按薪资排名”或“每笔订单下的商品按价格排序”时，PARTITION BY 是关键。它把结果集切分成多个逻辑分区，ROW_NUMBER() 在每个分区内独立计数。
例如：ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC) 会在每个 department_id 组内，按 salary 降序生成 1、2、3…
-
PARTITION BY后的列不必出现在SELECT列表中，但若要理解编号含义，通常需要一起查出 - 分区列如果有 NULL 值，所有 NULL 会被归为同一组（多数数据库行为一致）
- 不要混淆
PARTITION BY和GROUP BY：前者不聚合行，后者会压缩行数
ORDER BY 在 OVER 里决定编号稳定性，不是“随便选个字段就行”
编号是否可复现，完全取决于 OVER 中的 ORDER BY 是否能产生唯一、确定的排序。如果排序键有重复值（比如多人同薪资），ROW_NUMBER() 仍会强行分配不同序号，但每次执行的编号可能不一致（尤其在并行查询或无主键表中）。
解决办法是补全排序条件，让整个 ORDER BY 表达式具有确定性：
- 在
ORDER BY末尾加上主键，如ORDER BY salary DESC, employee_id - 避免仅用
ORDER BY created_at—— 若存在毫秒级相同的时间戳，仍可能不稳定 - PostgreSQL 中可加
ORDER BY ... NULLS LAST显式控制 NULL 位置，避免隐式差异
性能敏感场景下，ROW_NUMBER() 可能拖慢查询
窗口函数需扫描并缓存整个分区数据才能编号，对大数据量 + 复杂分区的查询，内存和 CPU 开销明显高于普通聚合。如果只是想取前 N 条，LIMIT/TOP 更快；如果只是做简单序号且无需分区，自增变量（MySQL）或 OFFSET 分页更轻量。
- 在 WHERE 中不能直接引用
ROW_NUMBER()别名（如WHERE rn = 1），必须用子查询或 CTE 包裹，这会增加一层执行计划嵌套 - PostgreSQL 中对超大分区，可考虑用
pg_stat_progress_window_aggregate视图观察执行进度 - SQL Server 中若提示
Warning: Null value is eliminated by an aggregate or other SET operation，说明ORDER BY列含 NULL，不一定影响结果，但值得检查
真正难的不是写出来，而是想清楚这个序号到底服务于什么——是展示用？过滤用？还是后续 JOIN 的依据？不同的目的，决定了要不要加 PARTITION BY、要不要补主键、甚至要不要换实现方式。
