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 方向都得一模一样。
