row_number() 必须配合 over 子句使用，且 over 中必须包含 order by；支持 partition by 实现分组内编号；不可在 where 或 group by 中直接调用，需通过子查询或 cte 引用。
ROW_NUMBER() 必须配合 OVER 子句，不能单独用
直接写 ROW_NUMBER() 会报错，SQL Server 要求它必须嵌在 OVER 中。核心是定义「按什么排序、在哪个范围内编号」——没 ORDER BY 就不合法，哪怕你只想按插入顺序排，也得显式指定一个确定性列（比如主键或时间戳）。
常见错误现象：Msg 4112, Level 15: The ranking function "ROW_NUMBER" must have an ORDER BY clause.
-
OVER (ORDER BY id)：按id升序生成连续行号 -
OVER (ORDER BY created_at DESC)：最新记录排第 1 行 - 避免用
OVER (ORDER BY (SELECT NULL))：看似“无序”，实则行为未定义，不同执行计划可能返回不同结果
分区（PARTITION BY）控制行号重置边界
如果需要“每个用户各自的行号”或“每月独立计数”，就得加 PARTITION BY。它把数据切分成逻辑组，ROW_NUMBER() 在每组内从 1 开始重新编号。
使用场景：查每个客户的最近 3 笔订单、统计各科室医生接诊顺序、按年份分组给销售记录打序号。
-
OVER (PARTITION BY customer_id ORDER BY order_date DESC)：每个customer_id内按时间倒序编号 - 注意
PARTITION BY的列必须出现在查询的SELECT或WHERE中可引用范围，不能是计算列且未被定义（如PARTITION BY YEAR(order_date)要确保该表达式在作用域内有效） - 性能影响：分区列若无索引，大表上
ROW_NUMBER()可能触发大量排序，建议在PARTITION BY + ORDER BY组合列上建复合索引
别名必须在外部 SELECT 中引用，不能在 WHERE 或 GROUP BY 直接用
窗口函数在逻辑处理顺序中晚于 WHERE 和 GROUP BY，所以不能在这些子句里直接写 ROW_NUMBER() OVER (...)。必须先用子查询或 CTE 把行号算出来，再过滤或分组。
典型错误：WHERE ROW_NUMBER() OVER (...) —— 报错，因为 <code>WHERE 执行时窗口函数还没运行。
- 正确做法：用 CTE 包一层，例如
WITH numbered AS (<br> SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn<br> FROM orders<br>)<br>SELECT * FROM numbered WHERE rn
- 也可以用派生表，但 CTE 更易读；注意 CTE 不是视图，每次引用都会重算，高频使用需权衡
- 如果只是取 Top N，
OFFSET-FETCH更轻量，但不支持分区场景
ORDER BY 的确定性决定行号稳定性
如果 ORDER BY 列存在重复值（比如多个订单同属一秒），SQL Server 会任意排序，导致多次执行同一语句得到不同行号。这不是 bug，是标准行为。
容易被忽略的地方：业务上要求“相同时间的订单按 ID 小的优先”，但只写 ORDER BY created_at 就不够。
- 补全排序键：
ORDER BY created_at DESC, id ASC，确保全序 - 对字符串或浮点字段排序要小心隐式转换或精度问题，可能导致意外重复
- 如果原始数据确实没有天然唯一排序依据，可在
ORDER BY末尾加(SELECT 0)强制稳定（SQL Server 允许，但不推荐依赖）
