DynamoDB将UpdatedDate作为GSI排序键是否存在性能问题？

为什么你没有观察到重复记录 #

你之前的认知是针对DynamoDB基表主键的规则：基表的分区键+排序键构成全局唯一的主键，不支持直接修改，要变更排序键只能删除旧条目再插入新条目，操作不当就会残留重复记录。但这个规则本身就不适用于GSI：
GSI的主键没有强制唯一性要求，且DynamoDB会自动维护基表到GSI的同步，你更新基表的UpdatedDate字段时，DynamoDB会直接定位到GSI中对应的条目更新排序键值，不会新增冗余条目，所以你没有观察到重复记录是正常现象。

该设计对GSI性能的影响 #

• 无性能影响的场景：如果GSI分区键MyComputedField的基数较高、值分布均匀，不会出现单个分区请求量过高的情况，那么UpdatedDate作为排序键是完全合理的，反而能提升时间范围查询的效率，性能不会有问题。
• 有性能风险的场景：如果MyComputedField基数极低（比如只有3-5个固定枚举值），所有写入都会集中到少数几个GSI分区的时间序末尾，会形成写入热区，导致吞吐量受限、请求延迟升高，这种场景下性能会受明显影响。

潜在的未注意问题 #

• 排序冲突：GSI没有唯一性约束，若两个基表项的MyComputedField和UpdatedDate完全一致，GSI查询时无法通过排序键区分这两个条目，若业务要求严格的排序确定性，可能会出现排序结果乱序的问题。
• 额外写入开销：每次更新基表的UpdatedDate字段时，都需要触发一次GSI的写入操作，会消耗额外的写入容量单位（WCU），如果更新UpdatedDate的频率极高，会明显拉高使用成本，高并发场景下也可能小幅提升写入延迟。
• 最终一致性延迟：GSI默认采用最终一致性同步，基表更新UpdatedDate后，GSI侧最多可能有数百毫秒的同步延迟，若业务对查询的实时性要求极高，可能会读到过期的时间值，甚至暂时查不到刚更新的条目。
• 查询适配性限制：排序键的优势是支持前缀匹配和范围查询，如果你的业务在该GSI上的查询很少用到时间范围筛选，那么UpdatedDate作为排序键无法发挥性能优势，反而会导致其他过滤条件需要扫描全分区，查询效率低下。

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