为什么在Cosmos SQL API查询的WHERE子句中包含分区键会增加某些查询的消耗RU？

Question

我想针对已使用的RU优化我的Azure Cosmos DBSQLAPI查询（部分原因是为了减少429个响应的频率）。

具体来说，我认为在WHERE子句中包含分区键将减少消耗的ru(例如，我阅读了https://docs . Microsoft . com/en-us/azure/cosmos-db/optimize-cost-queries和https://docs . Microsoft . com/en-us/azure/cosmos-db/partitioning-overview，这使我想到了这一点)。

然而，当我跑的时候

SELECT TOP 1 * 
FROM c
WHERE c.Field = "some value"
AND c.PartitionKeyField = "1234"
ORDER BY c.TimeStampField DESC

它消耗6个RU。

而没有分区密钥。

SELECT TOP 1 * 
FROM c
WHERE c.Field = "some value"
ORDER BY c.TimeStampField DESC

它消耗5.76 RUs，即更便宜。

（虽然根据所选的确切文档，上述数字有一些变化，但第二个查询总是更便宜，我已经针对最小和最大的分区进行了测试。

我的数据库目前有大约400，000个文档和29个分区(预计两者都将增长)。最大的分区大约有150，000个文档(不太可能超过这个数量)。

以上结果表明，我不应该在查询的WHERE子句中传递分区键。请有人解释一下为什么会这样，因为从文档中我认为相反的情况应该是正确的？

Answer 1

可能有几个原因，这取决于查询引擎决定使用哪个索引，或者是否有索引。

我可以说的第一件事是，这个容器中可能没有太多数据，因为没有分区键的查询越大，容器越大，就越昂贵，特别是当它们跨越物理分区时。

如果分区键上没有索引，并且在按 c.field 筛选后对其进行了扫描，则第一个分区键可能会更昂贵。

它也可能更昂贵，具体取决于是否存在复合索引以及是否使用它。

真的，尽管您不能对小容器进行查询指标并进行推断。衡量的唯一方法是将足够的数据放入容器中。这里的量太小，不值得优化。我会将您期望在生产中拥有的数据量放入这个容器中并重新运行您的查询。

最后，关于测量和优化，帕累托原则适用。你会疯狂地追求每一个优化。找到您的高并发查询并关注它们。

希望这对你有帮助。