DynamoDB表设计咨询：新增字段还是创建新表？

先纠正你的成本判断：两种方案的成本并非完全一致。如果把新参数加入旧表，仅10%的数据会增加少量存储开销，读写操作仍针对单表，不会额外增加读写成本；但如果新建表，那10%需要填充新参数的数据得同时写入旧表和新表，会多一倍写操作，直接提升写成本。后续如果需要关联新旧表查询，还会增加读操作次数和复杂度，进一步推高成本。

下面是业界普遍推荐的实践逻辑，分场景判断：

优先选择添加到现有旧表的场景 #

• 新参数和原有数据属于同一业务实体，查询时经常需要同时获取（比如查询用户基础信息时，大概率要查看对应的新增偏好参数）
• 业务逻辑上，新参数是原有实体的扩展属性，只是当前大部分数据暂未填充，未来可能逐步覆盖更多数据
• 遵循DynamoDB核心最佳实践——单表设计，避免跨表关联带来的复杂逻辑和额外性能/成本开销

适合创建新表的场景 #

• 新参数对应独立的业务实体，和原有数据关联极弱，几乎不需要一起查询（比如原有表存储订单主数据，新参数是订单的第三方物流统计数据，仅在特定报表场景才会关联）
• 新参数的读写模式和原有表差异极大：比如原有表是高频率读、低频率写，新表是高频率写、低频率读，分开设计能更精准地配置读写容量单元（RCU/WCU），优化成本
• 新参数涉及敏感数据，需要单独设置访问权限，和原有数据做权限隔离
• 未来新参数会快速衍生出大量关联属性，独立成表更利于后续业务扩展和维护

额外实操提示 #

• DynamoDB是无schema数据库，空属性不会占用存储，完全适配这种仅部分数据有新参数的场景，无需担心添加新属性会影响现有数据
• 单表设计的核心障碍从来不是数据量（DynamoDB支持无限水平扩展），而是主键和索引设计是否能匹配所有访问模式。如果现有表的主键设计已经能覆盖新参数的查询需求，加属性是最优解
• 若后续业务变化导致新参数的访问模式和原有表冲突，再通过ETL工具迁移数据到新表即可，无需一开始就做拆分

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