OFFSET-FETCH分页查询性能低下，如何优化？

针对你遇到的OFFSET分页在百万级结果集下耗时过长的问题，可通过以下几种方式优化：

1. 创建覆盖索引 #

你现有的Id、Name索引未包含过滤条件Color='red'，数据库需要先过滤出符合条件的行再排序，过程中可能需要回表查询数据。创建包含过滤、排序和返回字段的覆盖索引，让数据库直接通过索引完成查询，无需访问原表：

CREATE NONCLUSTERED INDEX IX_MyTable_Color_Id_Name 
ON MyTable (Color, Id, Name DESC);

这个索引的顺序是：先按Color过滤，再按Id、Name DESC排序，且索引包含了查询返回的所有字段（Name、Id、Color），完全覆盖你的查询需求，能大幅减少IO和排序开销。

2. 替换OFFSET为基于键的分页 #

OFFSET 10000会让数据库先扫描并跳过前10000条数据，这在大结果集下是性能瓶颈。改用基于上一页最后一条记录的键值来定位起始位置，避免全量扫描：
假设上一页最后一条记录的Id为@LastId，Name为@LastName，查询改写为：

SELECT Name, Id, Color
FROM MyTable
WHERE Color = 'red'
  AND (Id > @LastId OR (Id = @LastId AND Name < @LastName))
ORDER BY Id, Name DESC
FETCH NEXT 1000 ROWS ONLY

这种方式利用索引直接定位到下一页的起始行，无需处理前面的大量数据，性能提升非常明显。

3. 确认索引有效性与更新统计信息 #

• 查看执行计划，确认新创建的覆盖索引是否被使用。如果执行计划中仍出现表扫描/聚集索引扫描，可能是统计信息过期导致优化器选择了错误的执行路径，执行以下命令更新统计信息：

UPDATE STATISTICS MyTable;

4. 进阶：分区表优化（可选） #

如果表数据量远超百万级（如几千万条），可考虑按Color或Id对表进行分区，让查询仅扫描目标分区的数据，进一步降低IO开销。不过此操作需要结合业务场景评估成本。

内容的提问来源于stack exchange，提问作者havij