Azure Cosmos DB合成分区键缺失值时的查询性能与RU消耗问题

一、文档字段缺失导致合成分区键异常的情况 #

如果部分文档缺失deviceId或date字段，生成的partitionKey不符合预期（比如缺失deviceId时生成-2018、缺失date时生成abc-123-，甚至未生成partitionKey），会带来以下影响：

• RU消耗大幅飙升：查询这类异常文档时，Cosmos DB无法通过有效分区键定向到目标分区，只能执行全跨分区扫描。全扫描需要遍历所有物理分区、读取大量无关数据，RU消耗是定向查询的数倍甚至数十倍。
• 性能延迟显著增加：跨分区扫描需等待所有分区的查询结果汇总，单分区查询延迟通常在个位数毫秒，而跨分区扫描可能达到数百毫秒甚至更久，并发高时还可能触发超时。
• 数据分布失衡引发热分区：大量缺失字段的文档会集中到某个固定分区（比如所有-yyyy格式的partitionKey会落到同一分区），形成热分区。该分区会成为性能瓶颈，不仅查询延迟高，还可能触发分区扩容限制，影响整体服务稳定性。

二、查询条件缺失分区键组成字段的情况 #

当查询仅指定date（无deviceId）或仅指定deviceId（无date）时，即使文档的partitionKey都是正常的deviceId-date格式，也会出现以下问题：

• 跨分区查询不可避免：合成分区键是两个字段的组合，仅指定其中一个字段无法匹配唯一的分区键值，Cosmos DB必须扫描所有包含该字段值的分区。比如查询date=2018时，需要扫描所有deviceId对应的deviceId-2018分区，本质仍属于跨分区查询。
• RU消耗远高于定向查询：跨分区查询的RU消耗取决于扫描的分区数量和每个分区内匹配的文档数，通常是同时指定deviceId和date的定向查询的5-20倍，具体倍数由分区总数和数据分布决定。
• 性能波动剧烈：如果查询覆盖的分区数量多或部分分区数据量大，查询延迟会显著上升，且延迟波动性远大于定向查询，无法保证稳定的SLA。

三、额外注意事项 #

• 如果查询完全不指定任何分区键相关字段，会触发全集群扫描，RU消耗达到峰值，性能最差，需绝对避免。
• 若业务场景中经常出现仅按单个字段查询的需求，建议重新评估分区键设计：比如采用复合索引配合分区键，或调整分区键策略（将高频查询字段作为主分区键，另一个字段作为排序键），但调整分区键需要重新导入数据，成本较高。

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