使用不同PartitionKey查询Azure CosmosDB时检索文档数不一致问题

• 物理分区映射差异
  CosmosDB会将逻辑分区键值映射到物理分区。你那个包含108条文档的分区键，由于数据量占比极高，大概率被分配到独立的物理分区，查询优化器能直接定位到该物理分区，仅扫描区内文档就能找到TOP 1结果，所以RU消耗低、检索文档数少。而只有6条文档的分区键，可能因数据量过小，被放置在与其他逻辑分区（哪怕当前无数据）共享的物理分区中，查询时优化器无法精准定位到目标物理分区，只能跨所有物理分区遍历文档，导致RU飙升、检索文档数多。

• 查询优化器统计信息不足
  CosmosDB的查询优化器依赖容器的统计数据生成最优执行计划。小数据量的分区键由于文档数太少，系统生成的统计信息不够准确或未及时更新，优化器无法判断该分区键的文档仅存在于特定物理分区，只能采用全分区扫描的兜底策略。而大数据量的分区键统计信息足够明确，优化器能直接生成精准定位的执行计划。

• 初始物理分区分配特性
  容器创建初期，CosmosDB会预分配物理分区。如果两个分区键的创建时间有先后，或数据量差异过大，小数据量的分区键可能被分配到未充分利用的物理分区，该分区可能留存了早期的分区映射元数据，导致查询时需要扫描整个分区甚至多个分区才能找到目标文档。

• 检查物理分区分布：通过Azure门户进入CosmosDB容器的「数据资源管理器」，查看「分区键分布」，确认两个分区键对应的物理分区位置。如果小数据量分区键与其他分区共享物理分区，就能解释全扫描的问题。
• 显式指定分区键查询：使用SDK执行查询时，不要仅在WHERE子句中过滤分区键，而是通过PartitionKey参数显式指定目标分区键（比如new PartitionKey("5744b90c-208a-4d72-9675-ec5906afef80")），强制查询仅针对目标物理分区，观察RU消耗和检索文档数是否下降。
• 触发统计信息更新：执行一次针对小数据量分区键的全量计数查询（SELECT COUNT(1) FROM c WHERE c.PartitionKey = '5744b90c-208a-4d72-9675-ec5906afef80'），触发系统更新该分区键的统计数据，之后再执行TOP 1查询，看执行计划是否优化。

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