ROW_NUMBER()分页快的前提是执行计划走Top N Sort且跳过Sort运算符，否则需全表排序编号再过滤；必须用子查询或CTE先编号、外层WHERE过滤，ORDER BY须含唯一列兜底，索引须与OVER(ORDER BY)完全对齐。
ROW_NUMBER() 分页不是“写出来就能快”，它快的前提是执行计划走 Top N Sort、跳过 Sort 运算符；否则哪怕只取 20 条，10 万行就卡死。
为什么 ROW_NUMBER() 外层加 WHERE rn BETWEEN 会慢到崩溃
SQL 执行顺序决定：WHERE 在窗口函数计算前运行，rn 根本不可见。把 WHERE rn BETWEEN 101 AND 120 写在外层，等于强制数据库先给全表每一行算完 ROW_NUMBER()，再过滤——哪怕你只要第 2 页，也得扫完整张表。
- 正确做法：必须用子查询或 CTE 先完成编号，再对外层结果过滤
- 错误写法示例：
SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM t WHERE rn BETWEEN 101 AND 120→ 直接报错或全表扫描 - 优化器对
rn BETWEEN @start AND @end的识别度高于rn >= @start AND rn ，更易触发 <code>Top N Sort
ORDER BY 必须带唯一列兜底，否则翻页漏/重
只写 ORDER BY created_at DESC 是危险的：同一秒插入多条记录时，数据库不保证相同值下的物理顺序，ROW_NUMBER() 每次分配序号可能不同，导致某条记录在第 2 页和第 3 页重复出现，或彻底消失。
- 正确写法：
ORDER BY created_at DESC, id DESC（id是主键或唯一索引列） - 若排序字段允许 NULL，MySQL 需
ORDER BY IFNULL(created_at, '1970-01-01') DESC, id DESC；PostgreSQL 加NULLS LAST；SQL Server 默认 NULL 最小，通常无需处理 - 绝对别用表达式：
ORDER BY YEAR(created_at)或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_t_status_time_id ON t(status, created_at DESC, id DESC) - 单列索引（如只建了
created_at）对多列ORDER BY基本无效 - 高频
WHERE字段（如status = 'active'）要放联合索引最左列，才能被 Seek 利用 - WHERE 条件必须下推到子查询内层：
SELECT * FROM (SELECT ..., ROW_NUMBER()... FROM t WHERE status = 'active') t2 WHERE t2.rn BETWEEN ...
参数计算不防溢出，深度分页直接 Arithmetic overflow
常见报错：Arithmetic overflow error converting expression to data type int，根源是 (@page_index - 1) * @page_size 超过 2147483647。
- 必须用
BIGINT计算起始行：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 - 大偏移量主动拦截：
IF (@page_index > 5000) RAISERROR('Deep page not allowed', 16, 1)，比硬扛更稳
真正卡住人的从来不是语法，而是执行计划里那个藏不住的 Sort 运算符——它一出现，说明索引没对上、WHERE 没下推、或者 ORDER BY 里混进了函数。
