row_number()是唯一可靠可控的行号生成方式，必须配合over()使用，支持分组排序、编号解耦、索引优化及版本兼容性考量。
ROW_NUMBER() 是唯一可靠、可控的行号生成方式，不依赖表结构、不修改数据、可按任意逻辑分组排序。
ROW_NUMBER() 必须配合 OVER() 使用，否则语法报错
直接写 SELECT ROW_NUMBER(), * 会触发错误：Incorrect syntax near ')'。因为 ROW_NUMBER() 是窗口函数，必须声明计算范围（即 OVER 子句）。
-
OVER(ORDER BY insertTime)：全表按时间升序编号，编号从 1 开始连续 -
OVER(PARTITION BY UserIp ORDER BY insertTime)：先按UserIp分组，每组内再按时间编号，每组编号都从 1 重新开始 - 排序字段必须明确——不能用
*或模糊别名；若引用子查询列，需确保该列在OVER作用域内可见 - 不写
ASC默认升序，但显式写ORDER BY insertTime DESC才能得到最新记录排第 1 的编号
ORDER BY 在 ROW_NUMBER() 和最终结果中要分开处理
很多人误以为给 ROW_NUMBER() 加了 ORDER BY，整个查询结果就自动按那个顺序返回。不是这样。
-
ROW_NUMBER() OVER (ORDER BY Salary DESC)只影响行号生成逻辑，不控制最终结果集物理顺序 - 如果想让查询结果也按薪资降序排列，必须额外加顶层
ORDER BY Salary DESC - 两者可以不同：比如用
ROW_NUMBER() OVER (ORDER BY Name)编号，但最终ORDER BY Salary DESC展示——编号列和展示顺序完全解耦 - 没写顶层
ORDER BY时，SQL Server 不保证返回顺序，哪怕编号列看着“整齐”，那只是巧合
常见性能与兼容性陷阱
ROW_NUMBER() 在大数据量下容易成为性能瓶颈，尤其当排序字段无索引或涉及表达式时。
- 排序字段（如
insertTime）最好有索引，否则每次执行都触发全表扫描 + 排序内存开销 - 避免在
OVER中用函数包裹排序字段，例如ORDER BY YEAR(insertTime)会导致索引失效 - SQL Server 2005+ 全支持，但 Azure SQL 和较老版本（如 2000）不支持窗口函数，不能降级使用
- 如果只是需要简单递增编号且不关心分组逻辑，
IDENTITY列或SEQUENCE更轻量——但它们属于 DDL 层机制，无法在 SELECT 中动态控制
真正难的不是写出 ROW_NUMBER()，而是想清楚「编号依据什么分组」「按什么排序才有业务意义」「这个编号是否要参与后续筛选或分页」——这些决定了 PARTITION BY 和 ORDER BY 的组合是否合理，也决定了你能不能避开隐式排序依赖和性能雷区。
