CosmosDB - 使用 ORDER BY 的 TOP 1 查询 - 检索的文档计数和 RU

Posted 2023-04-14

【中文标题】CosmosDB - 使用 ORDER BY 的 TOP 1 查询 - 检索的文档计数和 RU

【英文标题】：CosmosDB - TOP 1 query with ORDER BY - Retrieved document count and RU

【发布时间】：2020-04-30 17:05:21

【问题描述】：

考虑以下查询：

SELECT TOP 1 * FROM c 
WHERE c.Type = 'Case' 
AND c.Entity.SomeField = @someValue
AND c.Entity.CreatedTimeUtc > @someTime
ORDER BY c.Entity.CreatedTimeUtc DESC

直到最近，当我运行此查询时，查询处理的文档数（查询指标中的 RetrievedDocumentCount）是满足前两个条件的文档数，无论“CreatedTimeUtc”还是 TOP 1。 只有当我添加了(Type DESC, Entity.SomeField DESC, Entity.CreatedTimeUtc DESC) 的复合索引并将它们添加到 ORDER BY 子句时，检索到的文档数才下降到满足所有 3 个条件的文档数（仍然不是预期的一个文档，但更好）。

然后，从几天前开始，我们注意到在我们的开发环境中不再需要复合索引，因为检索到的文档计数更改为只有一个文档（= TOP 中的数字，正如预期的那样），并且 RU/ s 显着减少。

我的问题 - 这是 CosmosDB 中的新改进/修复吗？我找不到任何关于这种方式的公告/文件。 如果是这样，推出是否已完成或仍在进行中？我们在不同地区有多个生产实例。

谢谢

【问题讨论】：

添加索引不能改变结果集，句号。这里发生了其他事情。

我几天前读过这篇博文：devblogs.microsoft.com/cosmosdb/april-query-improvements。改进可能是本博客所涵盖内容的一部分。

@TimBiegeleisen 我不是在谈论结果，结果是一致的。我说的是查询指标中的 RetrievedDocumentCount，即查询处理的文档数（直接影响 RU/s 消耗）。

@GauravMantri-AIS 我看过这篇文章，但它谈到了聚合函数和不等式过滤器/未定义值的过滤器的改进，这里不是这种情况。

【参考方案1】：

我们的查询引擎最近没有任何变化可以解释为什么这个查询突然变得更便宜了。

唯一可以解释这一点的是，与过滤器匹配的结果比以前少，而且我们的查询引擎能够执行优化，否则它无法对更大的结果集进行优化。

谢谢。

【讨论】：

再次添加复合索引并使用更大的数据集测试查询 - RetrievedDocumentCount 按预期减少到一个文档。谢谢