AWS DynamoDB部分GSI写入吞吐量为主表两倍的原因咨询

核心原因 #

带排序键的GSI，当主表写入操作涉及GSI分区键+排序键的变更（含重复设置相同值）时，DynamoDB会对GSI执行删除旧条目+插入新条目两次操作，直接导致写入吞吐量翻倍。

详细拆解 #

• GSI写入逻辑差异：
  • 无排序键的GSI：仅依赖分区键，只要分区键值未变化，哪怕更新主表其他属性，GSI仅执行1次写入操作，吞吐量与主表匹配（40）。
  • 带排序键的GSI：当主表写入操作修改了GSI的排序键属性（哪怕是把值改成和原来一样），DynamoDB会判定为GSI条目需要"替换"——先删除旧的键组合条目，再插入新的键组合条目，这两次操作各消耗1个WCU，最终总吞吐量是主表的2倍（80）。
• 趋势匹配的原因：主表的每次写入都触发了GSI的两次写入，所以两者的12小时使用趋势完全同步，只是数值翻倍。

验证方向 #

• 检查应用代码中的主表写入操作，确认是否每次都更新了那三个GSI的排序键对应属性（包括无意识的重复赋值）。
• 查看CloudWatch中GSI的WriteCapacityUnits指标，对比主表的WriteCapacityUnits，看是否严格呈2倍关系；同时观察GSI中DeleteItem和PutItem的占比，若Delete占比接近50%，则可确认是两次写入导致的。

优化建议 #

• 避免无意义的GSI键属性更新：在UpdateItem操作中，不要包含GSI排序键属性的赋值（除非确实需要修改其值）。
• 调整GSI键设计：如果排序键的变更频率高，考虑是否可以用其他属性作为排序键，或者重新评估该GSI的必要性，减少这类高消耗的写入操作。

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