DynamoDB多租户单表设计：分片查询值存租户项还是单独表？

一、分片查询值的存储抉择 #

• 嵌入租户实体属性：如果分片查询和租户核心业务绑定紧密，且查询频率低、数据量小，这种方式能保住单表设计的好处——统一数据模型、简化运维成本。但要注意，要是分片值需要频繁更新，或者查询时得过滤一堆无关属性，读写开销会显著上升；等租户数据量变大后，单条租户项的属性膨胀也会拖慢整体读写性能。
• 单独建查询表：如果分片查询是高频操作，或者需要单独做索引优化（比如给分片查询专门配置全局二级索引GSI），单独建表更靠谱。这样能把分片查询的负载和主业务表隔离开，避免主表被高频查询拖垮，还能给分片场景定制主键结构（比如用shardId+tenantId作为复合主键，从根源上分散热键流量）。

二、DAX加速分片查询的思路靠谱吗？ #

DAX确实能通过缓存高频查询结果提升性能，但它是补漏方案，而非根本性解决方案：

• 要是分片查询本身存在热键问题（比如某几个分片被集中访问），DAX只能缓解缓存命中时的压力，缓存失效或者未命中的时候，热键问题依然存在。
• 核心得先搞定主键的热键问题：比如把tenantId和分片标识（比如shardId）组合成复合主键（例如Partition Key用shardId#tenantId，或者shardId作为Partition Key、tenantId作为Sort Key），从数据分布层面把流量打散，再结合DAX缓存高频分片查询，效果才会真正达标。
• 另外，DAX有额外的成本和运维负担，要是分片查询的性能压力能通过调整表结构解决，没必要过早引入DAX。

总结 #

• 若分片查询低频、和租户业务强关联，把分片值嵌到租户属性里即可；要是高频、独立的查询场景，单独建表更合适。
• 用DAX加速分片查询的思路可行，但必须先优化主键设计解决热键根源问题，否则DAX无法彻底解决性能瓶颈。

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