为什么这个零结果Cosmos DB查询如此昂贵？

Question

我正在调查为什么我们在宇宙中耗尽了那么多RU。我们的写操作达到了预期的RU数量，但我们的读操作达到了极限——比我们的写操作高出一个数量级。我试着把它剥离到最简单的场景。在没有结果的分区上查询单个请求会使用2000个RU。为什么这么贵？

var query = new QueryDefinition("SELECT * FROM c WHERE c.partitionKey = @partionKey ORDER BY c._ts ASC, c.id ASC")
                    .WithParameter("@partionKey", id.Value)

using var queryResultSetIterator = container.GetItemQueryIterator<MyType>(query,
                requestOptions: new QueryRequestOptions
                {
                    PartitionKey = new PartitionKey(id.Value.ToString()),
                });

while (queryResultSetIterator.HasMoreResults)
            {
                foreach (var response in await queryResultSetIterator.ReadNextAsync())
                {
                    yield return response.Data;
                }
            }

集合的分区键是partitionKey。RU容量直接在容器上设置，而不是共享。我们有一个与where子句匹配的复合索引-\u ts asc，id asc。虽然我不知道这对不返回任何记录有什么影响。

不幸的是，当以这种方式查询时，SDK似乎没有提供已使用的RU，因此我一直在使用Azure monitor观察RU的使用情况。

有没有人能够阐明为什么这个查询，返回零条记录并仅限于单个分区会占用2kRU？

更新：

我刚刚在同一个存储帐户中的另一个数据库实例上运行了这个查询。两者配置相同。DB1有0MB，DB2有44MB。对于完全相同的不返回记录的操作，DB1使用111个RU，DB2使用4730RU——对于相同的无结果查询，这是40多倍。

添加更多细节：一致性设置为一致前缀。这是一个地区。

另一个更新：

我复制了仅通过Azure门户查询的问题，它与容器中的记录数有关。查看查询统计信息，好像它正在加载容器中的每个文档以搜索分区键。分区键不是性能最好的搜索方式吗？宇宙难道不知道在哪里可以找到设计上属于分区键的文档吗？

2445.38 RUs显示结果检索到的文档数：65671检索到的文档大小：294343656字节输出文档数：0输出文档大小：147字节索引命中文档数：0索引查找时间：0毫秒文档加载时间：8804.060000000001毫秒查询引擎执行时间：133.11毫秒系统功能执行时间：0毫秒用户定义功能执行时间：0毫秒文件写入时间：0毫秒

Answer 1

我最终找到了问题的根源。为了搜索分区键，它需要被索引。考虑到分区键用于决定文档的存储位置，这让我觉得很奇怪，所以你会认为宇宙天生就知道每个分区键的位置。

在索引项列表中包含分区键解决了我的问题。这也解释了为什么随着数据库规模的增长，性能会随着时间的推移而下降——它正在扫描每一个文档。