CosmosDB单对象查询：ReadItemAsync与GetItemLinqQueryable性能对比求证

我见过不少开发者针对这两种Cosmos DB单对象检索方式做过性能剖析，结论很明确：ReadItemAsync确实比Linq查询更快，而且在资源消耗上也更划算。

为什么ReadItemAsync更快？ #

• 它是SDK专为精准点读单条数据设计的API：直接通过主键（Item Id）+分区键定位到目标数据的存储位置，请求路径极短，不需要经过查询解析、索引扫描等额外环节。
• 对应的RU成本更低：默认情况下，读取一条1KB的文档只需要1个RU，这是Cosmos DB中成本最低的操作之一。
• 代码示例回顾：

  container.ReadItemAsync<Device>("devices", new PartitionKey(deviceId), null, default);
  

  这里要注意第一个参数是文档的id字段，第二个是分区键值，确保参数对应正确才能发挥最优性能。

Linq查询的性能瓶颈在哪里？ #

哪怕你写的是精准匹配的Where(a => a.DeviceId == deviceId).FirstOrDefault()，背后的逻辑也和点读完全不同：

• SDK会先把Linq表达式转换成Cosmos DB的SQL查询语句，这一步就多了一层转换开销。
• 查询请求发送后，Cosmos DB的查询引擎需要扫描对应分区的索引（哪怕是精准匹配），再返回结果，这个流程比直接点读多了好几个步骤。
• 如果你的DeviceId不是分区键或主键，还可能触发跨分区扫描，那性能差距会被进一步拉大。

实际测试数据参考 #

很多开发者的测试结果显示：在主键+分区键精准匹配的场景下，ReadItemAsync的响应时间通常是Linq查询的1/3到1/2，RU消耗也只有后者的一半左右。

内容的提问来源于stack exchange，提问作者Brandon McAlees