Pagination 为什么聚合分页查询比获取整个表花费更少的时间

我的数据库中有一个表，它的索引分为三列：

PropertyId

、

ConceptId

和

Sequence

。这个特定的表中有大约90000行，它通过这三个属性进行索引

现在，当我运行此查询时，所需的总时间大于2分钟：

SELECT *
FROM MSC_NPV
ORDER BY PropertyId, ConceptId, Sequence

但是，如果我这样对查询分页：

SELECT *
FROM MSC_NPV
ORDER BY PropertyId, ConceptId, Sequence
OFFSET x * 10000 ROWS
FETCH NEXT 10000 ROWS ONLY

所需的聚合时间（x从0到8）仅为20秒左右

这对我来说似乎是违反直觉的，因为分页需要在更简单的查询之外进行额外的操作，我们正在增加顺序网络调用所需的额外延迟，因为我根本没有并行化这个查询。而且，我知道这不是缓存问题，因为一个接一个地运行这些查询不会对延迟产生很大影响

所以，我的问题是：为什么一个比另一个快那么多

这似乎与我的直觉背道而驰，因为分页需要比简单查询更多的操作

分页查询有时工作非常快，如果您有正确的索引

例如，使用下面的查询

OFFSET x * 10000 ROWS
FETCH NEXT 10000 ROWS ONLY

您可以读取的最大行数仅为20000行。下面的一个示例也证明了这一点

RunTimeCountersPerThread Thread=“0”ActualRows=“60”ActualRowsRead=“60”

---

但是使用

select*

query。。您正在阅读所有的行

经过长时间的搜索，我发现性能差异（>2分钟）背后的原因是由于将数据库托管在Azure上。由于Azure跨多个分区（即多台计算机）对您在其上托管的任何表进行分区，因此运行如下查询：

SELECT *
FROM MSC_NPV
ORDER BY PropertyId, ConceptId, Sequence

将运行得更慢，因为查询在对所有分区排序之前先从中提取数据，这可能导致在同一个表上跨多个分区进行多个查询。通过对索引属性上的查询进行分页，我查看了一个特定的分区，并对存储在其中的表进行了查询，这就是为什么它的性能明显优于未分页的查询

为了证明这一点，我运行了另一个查询：

SELECT *
FROM MSC_NPV
ORDER BY Narrative
OFFSET x * 10000 ROWS
FETCH NEXT 10000 ROWS ONLY

---

与第一个分页查询相比，此查询运行异常，因为

叙述性
不是主键，因此Azure不使用它来构建分区键。因此，在
叙述中排序
需要与第一个查询相同的操作，并在其上进行额外的操作，因为必须事先获得整个表。
您根本没有回答我的问题。根据您提供的信息，等待时间应该随着我在x上的聚合而稳步增加（即
x=1
花费的时间比
x=2
等要少），但这并没有发生。每个查询都有一个固定的延迟，运行所有查询的总时间（20秒）仍然远远少于在一个查询中获取相同数据所需的时间（>2分钟）你根本没有提到这一点。这不是你的问题吗？这对我来说似乎是违反直觉的，因为分页需要更多的操作，而不仅仅是简单的查询，这是一个观察结果，即获取数据库中所有页面所需的时间远远少于获取整个数据库所需的时间，这似乎很奇怪。