OFFSET FETCH深分页越往后越慢，是因为其必须逐行扫描并跳过前N行，无法直接定位，导致逻辑读、排序溢出tempdb等开销随偏移量线性增长；应建覆盖联合索引、限制最大页码、避免NULL排序字段，并优先采用键集分页。
OFFSET FETCH 为什么在深分页时越来越慢
因为 OFFSET 10000 ROWS 不是“跳到第10001行”，而是让 SQL Server 从头扫描、逐行计数，跳过前10001行后再取数据。逻辑读随偏移量线性增长，排序算子还可能溢出到 tempdb。
这不是写法错，是机制决定的——哪怕你只查20条，它也得先“路过”前面一万行。
- 排序字段没索引 → 必然全表扫描 + 内存 Sort
- ORDER BY 含 NULL（比如 LEFT JOIN 后的字段）→ 排序不稳定，同一页可能漏行或重复
- OFFSET 参数用了表达式，如
OFFSET (@page - 1) * @size ROWS→ 存储过程中直接报错，SQL Server 不允许
嵌套查询里用 OFFSET FETCH 的硬性规则
子查询里的 ORDER BY 对外层 OFFSET 完全无效；必须把 ORDER BY 放在最外层 SELECT，否则报错 Invalid usage of the option NEXT in the FETCH statement。
常见翻车写法：
SELECT * FROM ( SELECT id, name FROM users WHERE status = 1 ORDER BY created_at DESC ) t OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;
正确写法：
SELECT * FROM ( SELECT id, name, created_at FROM users WHERE status = 1 ) t ORDER BY t.created_at DESC OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY;
- 外层
ORDER BY字段必须来自子查询输出列，且不能是函数包装（如UPPER(name)），否则索引失效 - JOIN 场景下，排序字段若来自右表（如
customers.name），必须建覆盖驱动表 + 关联字段的联合索引，例如IX_orders_cust_id_name -
OFFSET和FETCH后只能跟变量名或字面量，计算必须提前赋值：DECLARE @offset INT = (@page - 1) * @size
跨表分页如何避免重复/跳行
JOIN 后直接套 OFFSET FETCH，最容易出现数据不一致：同一页刷两次，结果不一样；往前翻一页，某条记录突然消失。
根本原因是排序键不唯一、含 NULL、或未落在驱动表上。
- 强制用主键补全排序，例如
ORDER BY status, created_at DESC, id DESC，确保每行顺序绝对确定 - WHERE 条件中避免对右表字段判 NULL（如
RIGHT_TABLE.field IS NOT NULL），否则执行计划可能改用 Nested Loop，放大排序不确定性 - 所有参与排序的字段，必须包含在同一张表的联合索引中；不要指望 SQL Server 能跨表合并索引
- 如果业务允许，加
WITH (NOLOCK)可降低阻塞，但要注意脏读——比如刚删除的订单可能短暂出现在下一页
存储过程里怎么安全返回总条数
别用 COUNT(*) OVER()，它会让每行都带总数，执行计划反而更重；也别写两遍 WHERE 条件——手抖改漏一个，总数和分页就对不上。
正确做法是拼接统一条件字符串：
DECLARE @where NVARCHAR(MAX) = ' WHERE status = 1 AND created_at >= ''2024-01-01'' '; DECLARE @sql NVARCHAR(MAX) = 'SELECT id, title FROM posts ' + @where + ' ORDER BY id DESC OFFSET @off ROWS FETCH NEXT @sz ROWS ONLY'; EXEC sp_executesql @sql, N'@off INT, @sz INT', @off = @offset, @sz = @size; <p>SET @sql = 'SELECT COUNT(*) FROM posts ' + @where; EXEC sp_executesql @sql;
- 必须用
sp_executesql而不是EXEC(@sql)，否则参数无法复用执行计划 - 对页码做硬拦截，比如
IF @page > 500 BEGIN RAISERROR('Page too deep', 16, 1) RETURN END，防止恶意请求拖垮服务 - 覆盖索引要包含所有 WHERE + ORDER BY 字段，否则即使写了索引，SQL Server 仍可能选择 Clustered Index Scan
实际部署时，最易被忽略的是排序字段的 NULL 处理和索引覆盖完整性——这两点不出问题时一切正常，一出就是间歇性漏数据，很难复现。
