为什么在Cosmos中，MS文档称ReadManyItemsAsync不执行查询操作，但实际上却执行了？

Question

根据微软文档，ReadManyItemsAsync 应该使用最便宜的查找类型，每个项目的 RU 费用为 1。https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/how-to-dotnet-read-item 为什么我在直接调用和跟踪中都看到 Query 的费用，而不仅仅是 Read？由于查询的成本至少是读取的 2.5 倍，这并没有道理。 我应该注意到，在我的测试中，我只发送了一个 id/partitionKey。它应该返回 1.xx 的费用。 我已经按照示例所述完全实现了代码，同时使用 ID 和 PartitionKeys。

            if (ids.Count != partitionKeys.Count)
                throw new ArgumentOutOfRangeException("ids and partitionKey counts must match"); 
            
            var container = Database.GetContainer(containerId); 
            List<(string, PartitionKey)> itemsToFind = new(); 
            for (int i = 0; i < ids.Count(); i++)
            {
                itemsToFind.Add((ids[i],new PartitionKey(partitionKeys[i])));
            }

            var result  = await container.ReadManyItemsAsync<T>(items: itemsToFind);
            return result; 

        }

但是当我看到那个调用时，我发现它正在使用查询并向我收费2.95RU。我完全意识到它也按有效载荷收费。这不是问题所在。问题是文档说它不执行查询...但我看到了查询。 所以我想问...这里到底发生了什么？

- macm

Answer 1

根据API文档：https://learn.microsoft.com/dotnet/api/microsoft.azure.cosmos.container.readmanyitemsasync?view=azure-dotnet#remarks

意在实现比使用IN语句获取大量独立项的查询更快的延迟。

主要场景是提供一个比 SELECT * FROM c WHERE c.id IN () and c.partitionKey = xx 更快的延迟选择，如果用户知道一组需要读取的项目的Id和Partition Key值，那么大多数人会这样做。

这就解释了为什么您看到查询操作，因为内部实现是优化后的查询（而不是IN查询）。

我同意您链接的文档(https://learn.microsoft.com/azure/cosmos-db/nosql/how-to-dotnet-read-item#read-multiple-items-asynchronously)有点误导性，因为它说它将进行点操作，我们会采纳您的反馈并改进措辞和解释以更好地说明。

- Matias Quaranta

---

嗨Matias。文档非常误导，因为它声称正在进行点读取。 Container.ReadManyItemsAsync<>根据您提供的唯一标识符和分区键返回项目列表。与查询相比，此操作通常更具性能，因为您将在列表中的所有项目上有效执行点读取操作。 我想票据中没有什么需要修复的，因为这是按设计实现的。 - macm

同意，我们已经着手更新文档，以更好地反映实现的功能。 目前，在ReadMany上没有点读使用。 - Matias Quaranta