為什么在 Cosmos 的 WHERE 子句中包含分區鍵 SQL API 查詢會增加某些查詢的消耗 RU？

Question

我想優化我的 Azure Cosmos DB SQL API 查詢消耗的 RU（部分是為了降低 42 響應的頻率）。

但是，當我跑步時

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 RU - 即更便宜。

（雖然根據所選的確切文檔，上述數字會有所不同，但第二個查詢總是更便宜，而且我已經針對最小和最大分區進行了測試。）

我的數據庫目前有大約 400,000 個文檔和 29 個分區（預計兩者都會增長）。 最大的分區有大約 150,000 個文檔（不太可能進一步增長）。

上面的結果告訴我，我不應該在這個查詢的 WHERE 子句中傳遞分區鍵。 請有人可以解釋為什么會這樣，因為我認為相反的情況應該是正確的？

Answer 1

可能有幾個原因，這取決於查詢引擎決定使用哪個索引或者是否有索引。

我可以說的第一件事是，這個容器中可能沒有太多數據，因為沒有分區鍵的查詢會隨着容器越大而變得越來越昂貴，尤其是當它們跨越物理分區時。

如果分區鍵上沒有索引並在通過 c.field 過濾后對其進行掃描，則第一個可能會更昂貴。

它也可能更昂貴，具體取決於是否存在復合索引以及是否使用它。

確實，盡管您無法獲取小型容器的查詢指標並進行推斷。 衡量的唯一方法是將足夠的數據放入容器中。 此外，這里的數量非常小，不值得優化。 我會將數據量放入您希望在生產中擁有的容器中，然后重新運行您的查詢。

最后，關於測量和優化，帕累托原則適用。 你會瘋狂地追逐每一個優化。 找到您的高並發查詢並專注於這些查詢。

希望這會有所幫助。