在使用 SQL Server 的 OFFSET 和 FETCH 进行分页查询时，我遇到了一个非常奇怪的现象：无论查询第一页还是其他页，只要 FETCH NEXT 的值是 1，查询性能就会变得非常糟糕，甚至比查询多行数据（如 FETCH NEXT 100）还要慢。这完全违背了直觉，因为按理说，查询的行数越少，性能应该越好。
经过一番排查，我发现问题可能出在以下几个关键点上。
1. 问题现象
无论查询第一页（OFFSET 0 ROWS FETCH NEXT 1 ROWS）还是其他页（如 OFFSET 100 ROWS FETCH NEXT 1 ROWS），只要 FETCH NEXT 的值是 1，查询速度就会变得异常缓慢，甚至需要 1 分钟以上。然而，当 FETCH NEXT 的值增加到 100 时，查询却能在 1 秒内完成。
2. 可能的原因
（1）排序和索引问题
OFFSET 和 FETCH 查询依赖于排序操作。如果 ORDER BY 中的字段没有索引支持，SQL Server 需要对整个数据集进行排序，这在数据量较大时会非常耗时。即使查询的行数只有 1，排序操作的开销也可能导致性能下降。
（2）查询优化器的选择
SQL Server 的查询优化器可能会根据查询的行数选择不同的执行计划。当 FETCH NEXT 的值为 1 时，优化器可能会选择一种不太高效的执行计划，导致性能问题。而当查询的行数增加时，优化器可能会选择更合适的执行计划。
（3）数据分布和 I/O 开销
如果数据表中的数据分布不均匀，或者数据存储在磁盘的较远位置，I/O 开销可能会显著增加。这种情况下，即使查询的行数很少，性能也可能受到影响。
3. 总结
最终采用了加大 FETCH NEXT ，这的确实是一种简单且有效的方法，尤其在面对分页查询性能问题时，可以快速缓解问题。然而，这种方法并不能解决根本问题，且在某些场景下可能会带来新的问题（如内存和带宽占用增加）。不过谁又能长期一家公司一直工作呢。
文章评论