使用不存在的ExclusiveStartKey查询DynamoDB GSI返回异常结果的问题

问题原因分析 #

1. GSI的最终一致性特性：主表的删除操作是强一致性，但GSI的索引更新是异步的，删除操作同步到GSI存在延迟。当你在分页查询GSI的同时删除主表记录，已删除的记录可能仍存在于GSI中，或者刚被同步删除，导致后续查询的LastEvaluatedKey指向的记录已不存在。
2. GSI与主表的LastEvaluatedKey逻辑差异：主表的LastEvaluatedKey是基于主键的排序逻辑生成的，即使对应记录被删除，DynamoDB仍能通过排序规则定位下一个起始位置。但GSI的LastEvaluatedKey是绑定到索引的物理存储条目上的，一旦对应记录从GSI中被同步删除，这个Key就失去了锚点，无法准确引导后续查询，进而出现跳记录或不返回LastEvaluatedKey的情况。

失效规律总结 #

• 删除操作同步到GSI的速度越快，LastEvaluatedKey失效概率越高；
• 分页limit越大，单次查询与删除的时间窗口越长，失效概率越高；
• GSI读写吞吐量不足时，同步延迟加剧，失效概率上升。

优化解决方案 #

方案1：先批量收集主键，再统一删除 #

• 流程：先通过GSI分页查询所有目标idB对应的记录，只提取主表的主键组合（idA+idB），将这些主键存入临时存储（内存、S3或消息队列）。等确认所有主键收集完成后，再调用BatchWriteItem批量删除主表中的记录。
• 优势：彻底规避查询与删除交叉导致的GSI不一致问题，收集阶段GSI数据稳定，分页不会出现LastEvaluatedKey失效。
• 注意：如果数据量极大，可分批次收集并持久化，避免内存溢出。

方案2：标记删除+延迟物理删除 #

• 流程：给表添加一个布尔字段（如is_marked_for_delete），修改GSI投影包含该字段。查询GSI时过滤掉is_marked_for_delete = true的记录，先将目标记录标记为待删除，等所有标记完成后，再批量删除主表中标记的记录。
• 优势：标记操作是强一致性的，GSI同步标记后，后续查询不会再获取到已标记的记录，避免分页混乱。如果不着急物理删除，也可以结合TTL让DynamoDB自动清理标记记录。

方案3：容错式分页查询逻辑 #

• 流程：当使用LastEvaluatedKey查询返回空或无LastEvaluatedKey时，不直接终止分页。改用基于排序键的范围查询重新定位：以上一批最后一条记录的idA为起点，执行idB = :target_idB AND idA > :last_idA的查询，并配合limit分页。
• 优势：即使LastEvaluatedKey失效，也能通过排序键的范围逻辑重新找到正确的起始位置，避免遗漏记录。

方案4：降低分页粒度 #

• 流程：将分页limit设置为较小的值（如50条以内），减少单次查询与删除的时间窗口，降低GSI同步延迟导致的LastEvaluatedKey失效概率。
• 优势：实现简单，适合数据量不大的场景，能有效减少异常情况的发生。

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