Cosmos DB：查询与点读效率差异及投影相关技术疑问

问题1：如何让Cosmos DB在服务器端完成投影，直接返回UserViewModel而非完整User文档？ #

必须使用查询API而非点读（ReadItemAsync）API，通过显式指定投影字段让服务器只返回所需数据：

• LINQ方式示例：

var query = container.GetItemLinqQueryable<User>()
    .Where(u => u.UserId == targetUserId)
    .Select(u => new UserViewModel { FirstName = u.FirstName })
    .ToFeedIterator();
var response = await query.ReadNextAsync();
var userViewModel = response.FirstOrDefault();

• SQL语句方式示例：

SELECT c.FirstName FROM c WHERE c.userId = @userId

点读API的设计是直接读取完整文档，不支持服务器端投影，因此无法通过它实现这个需求。

问题2：使用ReadItemAsync<UserViewModel>和ReadItemAsync<User>进行点读时，RU消耗均为4.76，是否意味着服务器返回完整文档后由客户端转换？ #

是的。点读操作的核心是读取完整的物理文档，不管你指定什么泛型类型，Cosmos DB服务器都会返回整个文档的JSON内容，之后由客户端SDK负责将JSON反序列化为你指定的UserViewModel或User对象。RU消耗只和文档大小、一致性级别等因素相关，和客户端的反序列化目标类型无关，所以两者的RU完全一致。

问题3：带分区键UserId的Where+Select查询（3.03 RU）为何比点读（4.76 RU）更高效？ #

两者的RU计算逻辑和数据处理流程不同：

• 点读操作会读取并返回完整的文档内容（你的文档平均120KB），RU计算主要基于文档的总大小，因此消耗较高。
• 带分区键的Where+Select查询，服务器会先通过分区键定位到目标分区，然后只提取FirstName字段返回，返回的数据量仅几十字节，远小于完整文档。虽然查询会增加少量索引查找的CPU开销，但数据传输量的大幅降低使得整体RU消耗比点读更低。

问题4：将Where条件改为非分区键FirstName时，RU仍为3.03，原因是什么？ #

这是因为你使用的是Cosmos DB模拟器，且测试数据量极小（仅200个文档）：

• 模拟器的RU计算逻辑和生产环境存在差异，小数据量下的索引扫描、跨分区查询开销几乎可以忽略。
• 即使查询非分区键，服务器也能快速扫描所有文档，加上投影返回的数据量依然很小，因此RU消耗没有明显变化。
  在生产环境中，如果数据量较大且未针对FirstName创建复合索引，这种跨分区查询的RU会显著上升——因为需要扫描多个分区的文档，CPU和IO开销都会大幅增加。

问题5：使用GetItemLinqQueryable<UserViewModel>但不加Select时，RU为3.8，比加Select时更高，原因是什么？ #

当你不加Select时，客户端SDK会生成SELECT * FROM c WHERE ...的SQL语句，服务器会返回完整的文档内容，之后由客户端SDK仅提取FirstName字段反序列化为UserViewModel。
这种情况下，服务器返回的数据量是完整文档的大小（120KB），因此RU比仅投影FirstName的查询（3.03 RU）更高；但查询是通过索引定位文档，其RU计算逻辑和点读不同，整体开销略低于直接点读（4.76 RU），所以最终RU为3.8。

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