为何仅以ID作为Partition Key不足以避免热分区问题？

你的应用以读操作为主，使用默认ID作为Partition Key却出现了热分区，结合你提供的集合存储情况：

即使ID具备唯一性，也不代表能实现请求的均匀分布，核心原因有这几点：

• 访问模式倾斜：如果读请求集中指向某一批ID（比如热门资源ID、近期生成的ID），哪怕ID唯一，这些请求都会落到对应分区，直接造成热分区。比如用户高频访问最新创建的N条数据，而这些ID若因生成规则（自增、时间戳前缀等）集中在少数分区，就会触发该分区资源耗尽。
• 哈希映射的局限性：Cosmos DB通过哈希函数将Partition Key映射到物理分区。哪怕ID唯一，若部分哈希值对应的分区被分配了更多请求（或存储了更多数据），也会导致热分区。但这种情况远不如访问模式倾斜常见。
• 存储与请求的双重叠加：从数据看第二个集合已达149.7MiB且触发Max RU，说明该分区存储的数据量更大，同时读请求又集中于此，双重压力直接导致资源瓶颈。

本质上，唯一的Partition Key只保证数据能分散存储，但如果请求不是均匀覆盖所有ID，就必然会出现热分区。

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