ROW_NUMBER()分页必须用三层嵌套结构：内层查原始数据并过滤，中间层加ROW_NUMBER()OVER(ORDER BY...)，外层WHERE过滤；过滤条件须放内层，ORDER BY需含唯一列兜底，关联视图分页须下推至基础表。
ROW_NUMBER() 分页必须写三层嵌套
两层写法看着省事，但执行计划大概率崩——优化器无法把 WHERE rn BETWEEN 下推到编号节点，结果是全表编号完再过滤，100 万行就扫 100 万次。三层结构才是稳定基线：最内层查原始数据 + 过滤条件，中间层加 ROW_NUMBER() OVER (ORDER BY ...)，最外层用 WHERE t.rn BETWEEN @start AND @end。
常见错误现象：Invalid column name 'rn'，因为别名没写或写在了外层；或者执行计划里出现“Table Scan”+“Compute Scalar”，说明编号发生在扫描之后。
- 过滤条件（如
WHERE status = 'active'）必须放最内层，让索引能生效 -
ORDER BY字段必须带唯一列兜底，例如ORDER BY created_at DESC, id DESC，否则重复时间戳会导致序号不稳定 - 别用
rn > @start AND rn ，SQL Server 优化器对 <code>BETWEEN更友好，能触发 TopN Sort 优化
ORDER BY 必须和索引完全对齐
ROW_NUMBER() 本身不慢，慢的是没索引强制排序。SQL Server 或 PostgreSQL 都要先完成排序才能编号，而排序成本随数据量线性上涨。如果你写的是 ROW_NUMBER() OVER (ORDER BY a DESC, b ASC)，那索引就必须是 CREATE INDEX IX_t_a_b ON t(a DESC, b ASC)，顺序、方向、列数一个都不能差。
典型踩坑：建了 INDEX(a) 单列索引，但 OVER 里是 ORDER BY a, b，结果还是走不了索引，执行计划里必出红色 “Sort” 算子。
- WHERE 中高频字段（如
status）建议放在联合索引最左列：CREATE INDEX IX_t_status_a_b ON t(status, a DESC, b ASC) - 避免在
ORDER BY里用函数，比如ORDER BY DATEADD(day, 1, a)，索引直接失效 - PostgreSQL 对 NULL 处理更敏感，
ORDER BY a DESC NULLS LAST要和索引定义一致，否则可能不走索引
参数计算必须防溢出、防越界
@page_index 和 @page_size 来自用户输入，不校验就会在深度分页时爆掉。最典型报错：Arithmetic overflow error converting expression to data type int，来自 (@page_index - 1) * @page_size 超过 2147483647。
- 起始行必须用
DECLARE @start BIGINT = (CAST(@page_index AS BIGINT) - 1) * @page_size + 1，漏+ 1就会让第 1 页丢第 1 条 - 硬限制
@page_size ≤ 100，防止恶意请求拖垮 tempdb 排序内存 - 页码兜底：
SET @page_index = NULLIF(@page_index, 0); IF @page_index IS NULL SET @page_index = 1; - 深度分页主动拦截：
IF @page_index > 5000 RAISERROR('Deep page not allowed', 16, 1)，比硬扛更可控
关联视图分页必须下推到基础表
对已定义的视图直接套 ROW_NUMBER()，99% 情况下等于白干——视图展开后，ROW_NUMBER() 可能被安排在 JOIN 和聚合之后，导致百万级中间结果集被编号。正确做法是把分页逻辑写进视图底层 SQL，在 JOIN 完成、字段裁剪前就编号。
错误写法：SELECT * FROM my_view ORDER BY id OFFSET 10000 ROWS FETCH NEXT 20 ROWS ONLY；正确写法是在视图对应的基础表 JOIN 块里加 ROW_NUMBER() OVER (ORDER BY o.id)，再外层过滤。
- 确保
ORDER BY字段来自驱动表（如主键o.id），避免按关联表字段（如u.name）排序引发额外排序 - JOIN 字段要有覆盖索引，例如
orders(user_id, status, id)，减少回表 - 执行计划里重点看
ROW_NUMBER()节点的Estimated Number of Rows是否接近你期望的页大小（比如 20），而不是动辄几十万
实际用起来最易忽略的点是：排序字段的稳定性不是“看起来一样”就够，而是必须由数据库保证每次执行都生成相同序号。哪怕只差一个 id DESC 没加，高并发场景下翻页就可能抖动。这不是玄学，是执行计划里是否能复用排序结果的硬门槛。
