DynamoDB使用固定值GSI实现全表查询是否会导致热分区问题？

结论 #

这个方案仅在极小数据量、低吞吐的场景下可用，整体不合理，必然会出现GSI热分区问题，不建议在生产环境大规模使用。

具体分析 #

• 有限适用场景：如果你的表总数据量低于1GB、总条目数小于10万，且全表查询的频率极低（比如每日仅1~2次后台统计），该方案可以暂时满足需求，确实能避免全表Scan操作带来的性能波动和额外开销。
• 热分区问题必然性：
  DynamoDB的单个物理分区有明确的性能和容量上限：最多支持1000 RCU（读容量单位）、1000 WCU（写容量单位），最多存储10GB数据。你将GSI的分区键取值固定为同一个值all，意味着：
  • 所有主表的写入请求都会同步写入该GSI的同一个分区，只要主表写入WCU超过1000，GSI首先会触发限流，成为整个表的写入瓶颈
  • 即使你开了自动扩缩容，DynamoDB也无法对该GSI做有效分区拆分：因为所有数据的分区键值完全相同，拆分后所有数据还是会落在同一个逻辑分区上，负载完全无法分散，热分区问题会持续恶化
• 额外成本问题：每一条写入主表的数据都会同步写一次GSI，相当于直接把表的写入成本提升了一倍，成本性价比极低。

替代方案 #

• 如果是离线批量查询全表的场景，直接使用DynamoDB原生的**Parallel Scan（并行扫描）**即可，性能是普通单线程Scan的数倍，不需要额外建GSI，成本远低于该方案，也不会影响在线业务负载。
• 如果需要在线低延迟查询全表，可以对GSI做散列拆分：将allIndex的取值拆分为N个分片（比如shard_0到shard_9共10个分片），写入数据时随机给allIndex分配一个分片值，查询全表时并行查询10个分片的结果再合并，可将负载均匀分散到N个分区，从根源上避免热分区问题，分片数可根据你的实际吞吐需求调整。

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