DynamoDB拆分条目/详情表是否属于糟糕的设计方案？

对你的场景而言，拆分为具备一对一关联关系的两张表是非常合理的优化方案，核心收益十分明确：

• 列表查询性能大幅提升：原架构下列表查询需要拉取包含大体积详情字段的整行数据，单条数据大小在4KB~22KB浮动，拆分后列表表单条数据固定在2KB以内，相同存储页/缓存块可承载的条目数提升数倍，分页查询时的IO开销、网络传输开销都会明显降低，缓存命中率也会更高
• 存储成本优化：通常列表字段的访问频率远高于详情字段，拆分后两张表可以采用分级存储策略，低频访问的详情表可以使用成本更低的冷存储介质，不需要和高频访问的列表数据共享高性能存储资源
• 索引维护成本降低：列表查询相关的索引只需要建立在小体积的列表表上，索引整体占用空间更小，数据增删改时的索引更新开销也会更低

除了你提到的需要双表同时更新、依赖TransactWrite保障写入一致性的问题外，还有这些潜在弊端需要评估：

• 关联查询开销：如果存在需要同时拉取列表字段+详情字段的业务场景，需要做两表关联查询或者两次单表查询，开销比原架构的单表单次查询更高，如果这类场景占比很高，拆分反而会带来负优化
• 冗余存储开销：一对一关联需要在两张表存储相同的主键/关联键字段，单条数据的冗余量不大，但如果条目规模达到千万级以上，累计产生的存储开销也需要纳入评估
• 一致性风险场景增加：除了正常写入流程，在数据备份恢复、手动数据订正、数据迁移等场景下，都需要同时操作两张表，任意环节出现遗漏都会导致数据不一致，例如只恢复了列表表的备份却忘记同步恢复详情表，就会出现条目存在但详情丢失的问题
• 开发适配成本提升：如果项目使用了ORM框架，一对一关联的查询、写入逻辑都需要额外配置，部分框架对一对一关联的懒加载、事务支持存在已知问题，需要额外做兼容性适配
• 后续扩展复杂度提升：如果后续数据增长到需要分库分表的量级，两张表必须采用完全一致的分片规则，才能保证关联查询的效率，分片逻辑的开发、维护成本比单表架构高很多

如果你的业务符合以下任意一种情况，可以考虑暂时不做拆分：

• 条目总规模不足10万条，列表分页每次拉取不超过20条，现有单表的查询延迟已经完全满足业务要求
• 80%以上的查询场景都需要同时用到列表字段和详情字段，拆分后关联查询的额外开销远大于列表查询的收益

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