row_number()分页必须带order by，否则报错；正确写法如row_number() over (order by id desc)，排序字段应含唯一列且避免表达式，外层用between过滤，索引与参数校验至关重要。
ROW_NUMBER() 分页必须带 ORDER BY，否则语法报错
SQL Server 要求 ROW_NUMBER() 必须配合 ORDER BY 子句，缺了直接报错：Window function 'ROW_NUMBER' requires an OVER clause with ORDER BY。这不是可选项，是硬性约束。
常见错误写法：ROW_NUMBER() OVER () 或漏写 ORDER BY；正确写法必须明确排序字段，比如：ROW_NUMBER() OVER (ORDER BY id DESC)。
- 排序字段最好包含唯一列（如主键），避免重复值导致序号不稳定——例如
ORDER BY created_at DESC, id DESC比单用created_at更可靠 - 如果业务允许，优先用聚集索引列排序（如
id），能减少排序开销 - 别在
ORDER BY里用表达式，比如ORDER BY DATEADD(day, 1, created_at)，会强制走Sort算子，性能崩盘
外层 WHERE 必须用 BETWEEN，不能用 > 和
WHERE rn BETWEEN @start AND @end 是唯一能触发 SQL Server “Seek + Top” 优化的写法；写成 WHERE rn > @start AND rn 会导致优化器无法下推 TopN，大概率全表扫描。
典型错误现象：执行计划里出现红色警告“Sort”或“Table Scan”，哪怕数据才几千行，查询也卡顿十几秒。
-
@start计算必须加 1：DECLARE @start INT = (@page_index - 1) * @page_size + 1，否则第 1 页会丢第 1 条 - 别名
rn不可省：ROW_NUMBER() OVER (...) AS rn，否则外层引用t.rn报错Invalid column name 'rn' - 子查询必须起别名（如
AS t），不然t.rn无法识别
索引必须和 OVER(ORDER BY ...) 完全对齐
慢不是因为 ROW_NUMBER() 本身，而是没索引——SQL Server 先排序再编号，没索引就硬扫全表+内存排序，5000 行就可能 20 秒。
关键不是“建个索引”，而是结构要严丝合缝。例如：
- 写的是
ROW_NUMBER() OVER (ORDER BY status, created_at DESC, id DESC)，那就得建：CREATE INDEX IX_logs_status_time_id ON logs(status, created_at DESC, id DESC) - 如果
WHERE常带status = 1，把status放最左；如果常查status IN (1,2)，这个索引效果会打折扣 - 单列索引对多列
ORDER BY基本无效，别指望CREATE INDEX IX_time ON logs(created_at)能加速ORDER BY created_at, id
参数计算和传参有三个硬坑必须防
OFFSET/FETCH 和 ROW_NUMBER() 都逃不开参数运算，但 ROW_NUMBER() 对溢出、越界更敏感，稍不注意就炸。
-
(@page_index - 1) * @page_size可能超int上限（2147483647）：用CAST(@page_index AS BIGINT)防溢出 - 页码必须兜底：
DECLARE @page_index INT = ISNULL(NULLIF(@input_page, 0), 1)，否则传 0 或负数会导致BETWEEN 0 AND 9错误 -
@page_size建议硬限制 ≤ 100，防止恶意请求触发tempdb溢出或内存 grant 不足；深度分页（如@page_index > 5000）建议直接RAISERROR拒绝
真正卡住人的从来不是语法，而是索引没对齐、参数没校验、排序字段用了函数——这些地方一错，ROW_NUMBER() 就从救命稻草变成性能黑洞。
