添加ORDER BY子句的DocumentDB使用过多的RU

Question

我有一个分区集合，在特定分区中有大约400,000个文档。理想情况下，这将更加分散，但我需要处理同一分区中的所有文档以进行事务考虑。我有一个查询，其中包括分区键和文档ID，它可以快速返回2.58 RU的使用情况。

此查询是动态的，可能构造为具有IN子句以搜索多个文档ID。因此我添加了一个ORDER BY来确保结果是一致的顺序，添加该条款然后导致RU猛增至近6000！鉴于WHERE子句应该在排序之前将结果过滤到少数，我对这些结果感到惊讶。看起来它似乎是在WHERE子句之前应用ORDER BY，它必须是正确的。是否有一些ORDER BY子句可以解释这种行为？

示例文件：

{
“DocumentType”：“InventoryRecord”，（PartitionKey，String）
“id”：“7867f600-c011-85c0-80f2-c44d1cf09f36”，（DocDB分配的GUID，存储为字符串）
“ItemNumber”：“123345”，（String）
“ItemName”：“Item1”（String）
}

查询看起来像这样：

SELECT * FROM c其中c.DocumentType ='InventoryRecord'
和c.id ='7867f600-c011-85c0-80f2-c44d1cf09f36'
按c.ItemNumber排序

Answer 1

您至少应该为ItemNumber添加范围索引。这应该确保，按预期排序。索引策略中的添加看起来像

{       “path”：“/ ItemNumber /？”，       “索引”：[         {           “善良”：“范围”，           “dataType”：“字符串”，           “精度”：-1         }       ]     }