Cosmos DB零结果查询RU消耗过高问题排查求助

我来帮你拆解这个Cosmos DB查询RU异常飙升的问题，从你描述的现象和更新信息来看，核心矛盾非常明确：明明指定了分区键精确匹配的查询，却没有按设计高效定位文档，反而全扫描了分区内所有文档，这直接导致RU消耗随分区内文档数量/数据量暴增。下面是具体的原因分析和解决思路：

从你通过Azure Portal拿到的查询统计就能看出关键异常：

加载了所有文档（65671条）搜索分区键，索引命中数为0，文档加载时间达8804.06毫秒，总消耗2445.38 RUs

正常情况下，指定PartitionKey并在WHERE子句中精确匹配分区键的查询，应该直接命中分区的主键索引，只扫描符合条件的文档（这里是0条），RU消耗应该极低（和DB1的111 RU接近）。现在出现全分区扫描，说明查询没有正确利用分区键索引。

1. 分区键参数类型不匹配 #

看你的代码里存在一个潜在的类型不一致问题：

// 查询参数传入的是id.Value（假设是原始类型，比如Guid/int）
.WithParameter("@partionKey", id.Value)
// 但PartitionKey构造器用了ToString()转成字符串
PartitionKey = new PartitionKey(id.Value.ToString())

Cosmos DB的分区键匹配是强类型敏感的：如果集合中存储的partitionKey字段是字符串类型，但你查询参数传了Guid/int，或者反过来，查询优化器会认为没有匹配的文档，进而退化为全分区扫描来逐一检查每个文档的分区键值。这正好能解释DB1（无文档）和DB2（大量文档）的RU差异——无文档时扫描成本可忽略，有大量文档时成本线性飙升。

2. 查询语句的参数拼写小问题 #

注意到你的查询语句里参数占位符是@partionKey（少了一个字母i，正确应该是@partitionKey），虽然代码里参数名和占位符保持了一致，但还是建议修正拼写避免潜在的混淆：

var query = new QueryDefinition("SELECT * FROM c WHERE c.partitionKey = @partitionKey ORDER BY c._ts ASC, c.id ASC")
 .WithParameter("@partitionKey", id.Value)

3. 复合索引的优先级干扰 #

你配置了复合索引_ts asc, id asc，但这个索引的前缀不是partitionKey。对于带分区键精确匹配的查询，Cosmos DB优先使用分区的主键索引来定位文档，而不是复合索引。如果主键索引因为类型不匹配无法命中，复合索引也无法弥补这个问题，最终只能全扫描分区。

第一步：统一分区键参数类型 #

检查集合中存储的文档的partitionKey字段类型（比如在数据资源管理器里查看一条文档的partitionKey是字符串还是原始类型），然后修改代码，确保查询参数和PartitionKey构造器的类型完全一致：

// 示例：如果集合中partitionKey是字符串类型，统一转成字符串
var partitionKeyValue = id.Value.ToString();
var query = new QueryDefinition("SELECT * FROM c WHERE c.partitionKey = @partitionKey ORDER BY c._ts ASC, c.id ASC")
 .WithParameter("@partitionKey", partitionKeyValue);
using var queryResultSetIterator = container.GetItemQueryIterator<MyType>(query, requestOptions: new QueryRequestOptions { 
    PartitionKey = new PartitionKey(partitionKeyValue) 
});

第二步：验证索引命中情况 #

在Azure Portal的数据资源管理器中，打开对应的集合，用查询编辑器执行相同的查询，然后查看查询统计：

• 确认是否显示“Partition key exact match”（表示命中了分区键索引）
• 查看扫描的文档数是否为0（因为是无结果查询）
• 检查执行计划是否显示利用了分区键索引

第三步：调整索引配置 #

对于这个查询，其实不需要额外的复合索引——因为指定了分区键精确匹配，加上ORDER BY的_ts和id，Cosmos DB会自动利用分区内的主键索引加上排序字段的单字段索引（默认启用）。你可以尝试暂时移除这个复合索引，看是否能解决问题。

你提到的DB1（0MB，111 RU）和DB2（44MB，4730 RU）的差异，完全符合全分区扫描的特性：RU消耗和扫描的文档数、数据量直接相关，当分区内没有文档时，扫描成本极低；当分区内有大量文档时，扫描所有文档的RU会呈线性增长，同时加载时间也会大幅上升。

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