row_number() 本身不解决深分页性能问题，真正提速需索引对齐、过滤下推和主动拦截；常见慢因是order by字段无联合索引、where未下推、排序用表达式、参数溢出等。

ROW_NUMBER() 本身不解决深分页性能问题，它只是让深分页“可控”——真正快的关键是索引对齐、过滤下推和主动拦截。

为什么 ROW_NUMBER() 在深度分页时仍可能很慢

常见错误现象：第 1 万页查询耗时 8 秒以上，执行计划里出现 Index Scan 或 Sort 占比超 90%。这不是 ROW_NUMBER() 的锅，而是它被迫在无索引或全表数据上排序编号。

• ORDER BY 字段没建联合索引，比如写 ORDER BY created_at DESC, id DESC 却只建了 IX_logs_created_at 单列索引
• WHERE 条件写在外层，导致 ROW_NUMBER() 对全表编号，再过滤——rn BETWEEN 100001 AND 100020 实际扫描了百万行
• 排序字段用了表达式，如 ORDER BY DATEADD(day, 1, created_at)，索引完全失效，强制 Sort
• 参数计算溢出：(@PageIndex - 1) * @PageSize 超过 INT 上限（2147483647），报 Arithmetic overflow error converting expression to data type int

必须建的索引结构怎么配才生效

索引不是“有就行”，必须和 OVER (ORDER BY ...) 字段顺序、方向、覆盖条件三者严格一致。

• 若分页语句是 ROW_NUMBER() OVER (ORDER BY status, updated_at DESC, id DESC)，则索引必须是 CREATE INDEX IX_orders_status_updated_id ON orders(status, updated_at DESC, id DESC)
• 如果常带 WHERE category_id = 5，把 category_id 加到索引最左列：CREATE INDEX IX_orders_cat_status_updated_id ON orders(category_id, status, updated_at DESC, id DESC)
• 避免在 ORDER BY 中使用函数、计算字段或 CAST，否则索引无法命中
• PostgreSQL 需注意 NULLS LAST / NULLS FIRST 是否与索引定义一致，否则可能弃用索引

存储过程里防崩的硬性校验点

用户输入的 @PageIndex 和 @PageSize 是高危变量，不校验就等于给拖库开后门。

• 页码兜底：DECLARE @PageIndex INT = ISNULL(NULLIF(@input_page, 0), 1)，防传入 0 或 NULL
• 大小限制：IF @PageSize > 100 SET @PageSize = 100，防止大结果集压爆 tempdb
• 起始行计算必须加 1：DECLARE @StartRow BIGINT = (CAST(@PageIndex AS BIGINT) - 1) * CAST(@PageSize AS BIGINT) + 1，漏 + 1 第 1 页就丢首条
• 深度拦截：IF @PageIndex > 5000 RAISERROR('Deep page not allowed', 16, 1)，比硬扛更可靠

WHERE 条件该写在哪一层才不白忙

外层 WHERE rn BETWEEN ... 只是最后筛选，真正的性能杠杆在内层——它决定了 ROW_NUMBER() 给多少行编号。

• ✅ 正确：业务过滤全部下推到最内层子查询，例如 FROM orders WHERE status = 'shipped' 写在 ROW_NUMBER() 所在的子查询里
• ❌ 错误：把 WHERE status = 'shipped' 放在外层，等同于先给全表编号再过滤，索引形同虚设
• 别省略别名：AS rn 不可省，否则外层引用报 Invalid column name 'rn'
• 不要用 rn >= @start AND rn ，虽然语义等价，但部分版本优化器对 <code>BETWEEN 更友好

深分页真正的瓶颈从来不在语法，而在执行路径是否被约束——索引没对齐，再好的写法也救不了；参数没兜底，再小的请求也能拖垮服务。最容易被忽略的是：你写的 ORDER BY 和你建的索引，连逗号前后顺序、ASC/DESC 方向都得一模一样。