Cosmos DB使用非分区键索引属性查询是否属于合理最佳实践？

为什么全索引场景下仍需优先基于分区键执行查询 #

Cosmos DB 采用分布式分片存储架构，所有数据按分区键打散存储在不同的物理分区中，索引也是每个物理分区独立维护，这一特性决定了分区键在查询成本上的核心影响：

• 不带分区键的查询属于跨分区扇出查询，即使被查询字段已经建了索引，请求也需要下发到每一个物理分区，逐个查询本地索引后再合并返回结果
• 你当前百万级数据下查询仅消耗3.32RU，本质是当前总数据量还未突破单物理分区的存储上限（通常为50GB），不需要跨分区扇出，所以表现接近单分区查询。当后续数据量增长、物理分区数逐步扩容到10个、100个甚至更多时，这类跨分区查询的RU消耗会随分区数线性增长，查询延迟也会同步上升
• 跨分区查询还会占用更多系统吞吐量配额，高并发场景下更容易触发限流，极端情况还会触及跨分区查询的结果条数上限
• 带分区键的查询属于单分区查询，只会请求目标数据所在的单个物理分区，RU消耗不会随总数据量增长而变化，延迟稳定，是官方明确的最优查询模式

基于非分区键 UserIds 的查询是否属于合理最佳实践 #

需要结合使用场景判断：

• 如果是低频、低并发的后台运维类查询，当前RU消耗可控的情况下可以临时使用，不属于严重设计错误
• 如果是高频、面向用户的核心业务查询，不属于最佳实践，存在明确的长期风险：
  • 后续数据扩容拆分出多个物理分区后，相同查询的RU成本会成倍上涨，比如拆分到10个分区时RU可能涨到30+，100个分区时会涨到300+
  • 高并发下这类查询会快速耗尽你的RU配额，导致正常业务请求被限流
• 可选优化方案：
  • 如果核心查询场景就是按UserId查询关联的tank信息，建议调整数据模型，将分区键改为UserId，或者新增一张以UserId为分区键的关联映射表，查询时先查映射表拿到对应tankId，再用tankId作为分区键查询原表
  • 如果不想调整现有模型，也可以为UserIds配置专门的复合索引，降低后续多分区场景下的单分区查询消耗，但无法解决跨分区扇出的本质问题

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