row_number()分页快的前提是执行计划走top n sort且避免sort运算符，需排序字段含唯一列兜底、索引与order by完全对齐、where条件下推至子查询内层。
ROW_NUMBER() 分页不是“写出来就能快”，而是必须让执行计划走 Top N Sort、跳过 Sort 运算符，否则 10 万行就卡死。它比 OFFSET/FETCH 稳，但稳的前提是——你没在排序字段上动歪脑筋。
ORDER BY 必须带唯一列兜底
只写 ORDER BY created_at DESC 是危险的：同一秒插入多条记录时，ROW_NUMBER() 分配序号不一致，翻页会漏或重复。数据库不保证相同值下的行物理顺序。
- 正确写法：
ORDER BY created_at DESC, id DESC（id是主键或唯一索引列） - 如果排序字段可能为
NULL，PostgreSQL 要加NULLS LAST，SQL Server 默认按NULL最小处理，MySQL 则需IFNULL(created_at, '1970-01-01') - 别用表达式，比如
ORDER BY YEAR(created_at)或ORDER BY UPPER(name)——索引失效，必然触发全表Sort
索引必须和 OVER(ORDER BY) 完全对齐
ROW_NUMBER() 本身不慢，慢是因为没索引；SQL Server 必须先排序再编号，没索引就强制 Sort，I/O 和内存直接崩。
- 若写
OVER (ORDER BY status, created_at DESC, id DESC)，索引必须是CREATE INDEX IX_tab_status_time_id ON table_name(status, created_at DESC, id DESC) - 单列索引（如只建了
created_at）对多列ORDER BY基本无效 - WHERE 条件高频字段（如
status = 'active'）要放在联合索引最左列，才能被 Seek 利用
WHERE 条件必须下推到内层子查询
把过滤条件写在外层 WHERE，等于全表编号完再筛——哪怕你只要 20 条，也得给 100 万行编完号。
- ✅ 正确：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY created_at DESC, id DESC) AS rn FROM logs WHERE status = 'processed' -- ← 这里过滤！ ) t WHERE t.rn BETWEEN 101 AND 120
- ❌ 错误：
WHERE status = 'processed'写在外层，或写成WHERE t.rn >= 101 AND t.rn （部分优化器无法下推谓词） -
rn BETWEEN @start AND @end比rn > @start AND rn 更易被优化器识别为 TopN 场景
参数计算和类型溢出最容易踩坑
深度分页常见报错 Arithmetic overflow error converting expression to data type int，根源是 (@page_index - 1) * @page_size 超过 2147483647。
- 用
DECLARE @start BIGINT = (CAST(@page_index AS BIGINT) - 1) * CAST(@page_size AS BIGINT) + 1 - 页码必须兜底：
SET @page_index = NULLIF(@page_index, 0); IF @page_index IS NULL SET @page_index = 1 -
@page_size建议硬限制 ≤ 100，防止恶意请求拖垮tempdb或触发内存 grant 不足 - 超过 5000 页主动拦截：
IF @page_index > 5000 RAISERROR('Deep page not allowed', 16, 1)，比硬扛更实际
真正卡住性能的，往往不是函数怎么写，而是索引没对齐、WHERE 没下推、或者排序字段悄悄用了函数——这些地方一错，ROW_NUMBER() 就从“稳定分页”变成“全表排序定时炸弹”。
