SQL Server OFFSET-FETCH越往后越慢，是因为OFFSET需逐行扫描并跳过前N行，无法直接定位，导致逻辑读、内存Sort溢出tempdb等开销随偏移量线性增长；应建覆盖联合索引、限制最大页码、避免NULL排序字段，并优先采用键集分页。
SQL Server 存储过程中用 OFFSET-FETCH 做分页，为什么越往后越慢？
因为 OFFSET 10000 ROWS 要求 SQL Server 先扫描并跳过前 10001 行，再取下一批——哪怕你只想要 20 条。它不跳索引节点，而是逐行计数，深分页时逻辑读飙升，内存 Sort 算子可能溢出到 tempdb。
实操建议：
- 必须在
ORDER BY字段上建**覆盖性联合索引**，例如分页按status, created_at DESC, id DESC排序，就建CREATE INDEX IX_orders_status_created_id ON orders(status, created_at DESC, id DESC) - 避免在
ORDER BY中混用 NULL 值字段（如 LEFT JOIN 后的右表字段），否则排序不稳定，OFFSET 可能漏行或重复 - 对页码做硬限制：比如
IF @PageIndex > 500 BEGIN RAISERROR('Page too deep', 16, 1) RETURN END，防止用户传page=10000直接拖垮服务
如何在存储过程里安全返回总条数而不 double-scan？
SELECT COUNT(*) 和分页查询必须用**完全一致的 WHERE 条件字符串**，否则总数和分页数据对不上。但两次全表扫描在大数据量下确实慢——这不是语法问题，是设计权衡。
实操建议：
- 用局部变量拼 WHERE，确保分页查询和 COUNT 查询共用同一段条件逻辑，例如：
SET @where = ' WHERE status = 1 AND created_at >= ''2024-01-01'''；然后分页查用 <code>... FROM orders ' + @where + ' ORDER BY ... OFFSET ...，总数查用'SELECT COUNT(*) FROM orders ' + @where - 别用
COUNT(*) OVER()想“一箭双雕”：它会让每行都带总数，但执行计划仍要扫全表+加窗口聚合，比分开查还重 - 如果业务允许弱一致性（比如后台报表），可加
WITH (NOLOCK)降低阻塞，但需评估脏读风险
跨表 JOIN 分页时，ORDER BY 放在哪张表字段上才不翻车？
必须落在**驱动表（通常是主实体表）的高选择性字段上**。例如查订单+用户信息，ORDER BY u.name 很危险：LEFT JOIN 后 u.name 可能为 NULL，且没索引就必然走全表排序；而 ORDER BY o.order_date DESC, o.id DESC 就稳定得多。
实操建议：
- JOIN 后所有
ORDER BY字段都来自主表（如orders），且该组合必须有对应索引 - 动态 SQL 拼接表名/字段名时，一律套
QUOTENAME()，防注入，例如：' FROM ' + QUOTENAME(@MainTable) + ' o LEFT JOIN ' + QUOTENAME(@JoinTable) + ' u ON o.user_id = u.id' - 模糊搜索别写
u.name LIKE '%' + @kw + '%'，改用u.name LIKE @kw + '%'并给u.name加索引，否则LIKE前导通配直接放弃索引
有没有比 OFFSET-FETCH 更快的分页方案？
有，但适用场景有限。键集分页（Keyset Pagination）用上一页最后一条的排序字段值做条件，例如 WHERE order_date ，它不依赖偏移量，性能恒定，但要求前端记住上一页末位 ID，且不支持跳页。
实操建议：
- 适合无限滚动、下拉加载场景，不适合带页码跳转的管理后台
- 必须保证排序字段组合**全局唯一且非空**，否则多行同值会导致漏数据；推荐用主键兜底，如
ORDER BY created_at DESC, id DESC - 存储过程里不能只靠参数判断是否启用键集分页——要检查
@last_id IS NOT NULL且@page_index = 0这类约定，否则容易和传统分页逻辑混淆
