不使用Scan操作获取DynamoDB中各PK的最小重试次数记录

明确说：完全可以不用Scan操作，核心是跳出关系型数据库的聚合思维，利用DynamoDB的索引设计或写入时的状态维护来实现——毕竟DynamoDB是面向查询设计的数据库，要从它的特性出发解决问题。

1. 写入时维护最小重试记录（最推荐，性能最优） #

这是从根源上解决问题的方案，后续查询零开销：

• 写入新记录前，针对当前PK执行一次Query，确认该PK下现有记录的最小retries值。
• 如果新记录的retries更小，就额外写入一条标记为最小重试的专属记录：比如给SK加固定前缀（如MIN_RETRY#87bee31f-03da-42f3-92ec-5b8e5e1e726f），或者给这条记录单独建一个GSI——把GSI的PK设为固定值（如ALL_MIN_RETRIES），原表PK作为GSI的SK。
• 之后要获取所有PK的最小重试记录时，直接Query这个GSI的PK=ALL_MIN_RETRIES，就能一次性拿到所有目标记录，完全不需要扫描主表。

2. 用全局二级索引（GSI）处理现有数据 #

如果没法修改写入逻辑，就给主表建针对性的GSI：

• 方案A：GSI的分区键设为原表的PK，排序键设为retries，并投影必要属性（原SK、retries）。此时每个GSI分区对应原表的一个PK，且分区内记录按retries从小到大排序。后续只需扫描GSI，对每个PK只保留第一条（retries最小）的记录，最后用BatchGetItem批量获取完整数据——GSI的数据量远小于主表，扫描开销大幅降低。
• 方案B：把固定值（如ALL_MIN_RETRIES）作为GSI的PK，排序键设为retries#原PK，所有记录会在同一个GSI分区里按retries排序。扫描时遍历数据，对每个原PK去重，只保留第一次出现的（即retries最小的）记录即可，这种GSI的存储开销更小。

3. 万不得已时的优化Scan方案 #

如果以上两种都无法实现，只能用Scan，但可以大幅降低开销：

• 只投影必要属性：在Scan请求中指定ProjectionExpression为PK, SK, retries，减少数据传输量。
• 开启并行Scan：设置TotalSegments参数，将扫描任务拆分到多个线程/进程，提升扫描速度。
• 客户端侧分组去重：扫描过程中用哈希表（比如Python的dict）按PK分组，只保留每个PK下retries最小的SK，扫描完成后再用BatchGetItem批量获取对应完整记录，避免处理全表冗余数据。

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