使用日期作为Azure Cosmos DB分区键是否适配按日期和ID查询的场景？

1. 当前分区键选择的合理性与优化空间 #

你当前选择date作为分区键是完全合理的，适配你现有的业务场景：

• 所有业务查询都携带了分区键date，属于单分区精准查询，不会产生跨分区查询的额外开销，当前2.9RU的消耗已经处于非常低的水平
• 每日6000条的写入量会均匀分散到不同日期的逻辑分区中，不会出现单分区写入热点，单分区10GB的存储上限足够承载数年的日增数据，不会触发分区拆分的性能影响

可优化的方向包括：

• 最高效优化：你的查询条件正好是「分区键值+文档id」的组合，完全可以不用执行SQL查询，改用Cosmos DB的点读（Read Item）接口直接读取目标文档，RU消耗会进一步降低到2RU以内，性能也更好
• 前瞻优化：如果后续会产生「查询单个用户近N天所有结果」这类跨日期的查询需求，可以考虑改用合成分区键，例如将id和date拼接为{id}_{date}作为分区键，单天查询和跨天查询都可以灵活适配，现有场景下不需要额外调整
• 轻量优化：将查询语句从SELECT *改为SELECT c.Result FROM c，只返回你需要的字段，减少数据传输开销，也能小幅降低RU消耗

2. 数据量增长对单请求RU消耗的影响 #

不会随总数据量增长升高，原因如下：

• 你的查询每次都明确指定了分区键，会直接定位到目标逻辑分区执行，集合总数据量增长只会增加逻辑分区的总数量，不会影响单个分区内的查询效率
• 你使用的是id和date的精准匹配查询，依赖Cosmos DB的自动索引做精准匹配，只要单文档体积没有变大、查询逻辑没有调整，无论总数据量是几万还是几亿，单次查询的RU消耗都会稳定在当前水平，不会出现明显上涨
• 只有当你后续调整文档结构、增加单文档存储体积，或者修改查询逻辑为模糊匹配/跨分区查询时，RU消耗才会出现上升，和集合总数据量没有直接关联

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