Azure Cosmos DB分区键使用疑问：强制要求场景及数据建模优化咨询

Cosmos DB不同操作对分区键的强制要求，是由操作的底层执行逻辑决定的：

• 你之前用的LINQ to SQL查询属于普通SQL查询，未指定分区键时，Cosmos DB默认会自动执行跨所有物理分区的扇出查询，后台会遍历所有分区匹配查询条件，因此无需你主动传入分区键也能运行，只是这类查询的RU消耗和延迟通常高于单分区查询。
• 存储过程在Cosmos DB的设计中是单分区绑定执行的，所有存储过程的运行上下文都被限制在单个逻辑分区内，不支持跨分区执行，因此调用时必须传入分区键定位到对应分区的存储过程实例，否则无法正常触发执行。

建模合理性评估 #

你当前的建模确实不符合Cosmos DB的核心最佳实践：Cosmos DB分区键设计的核心原则是分区键必须匹配最高频的查询模式。你对外的核心查询入口是按catalogId检索，没有携带分区键supplierId，等于最高频的查询天然不匹配分区键设计，自然会出现分区键依赖的问题。

优化建议 #

• 优先调整分区键设计：如果按catalogId查询是你最高频的查询场景，直接调整分区键为catalogId即可。对于属于多个catalog的商品，做写入侧的冗余处理，每个关联的catalog分区都写入一份商品副本，查询时直接用传入的catalogId作为分区键调用存储过程，完全不需要感知supplierId的存在，是性能和开销最优的方案。
• 数据访问层封装分区键查询逻辑：如果无法调整现有分区键设计，不要将supplierId的依赖暴露到上层API，在数据访问层内部封装两步查询逻辑：第一步先通过带索引的catalogId查询拿到所有关联的supplierId，第二步用拿到的supplierId列表并行调用对应分区的存储过程，聚合结果后返回给上层，上层完全感知不到底层的分区键逻辑，也不会破坏现有API契约。
• 替换存储过程实现方案：如果存储过程的逻辑复杂度不高，直接将存储过程内的逻辑迁移到应用层的SQL/LINQ查询实现，无需使用存储过程就可以避免强制传分区键的要求，走默认的跨分区扇出查询即可，适合QPS较低、对RU成本敏感度不高的场景。

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