如何在DynamoDB中检索所有未设置Time To Live属性的条目？

这个需求完全可以实现，针对8.5亿条记录的超大表，给你两种可落地的方案，以及对应注意事项：

方案1：自行编写Scan+批量更新逻辑（灵活度高，可自定义控制节奏） #

• 调用Scan接口执行全表扫描，配置FilterExpression = attribute_not_exists(你的TTL字段名)过滤出未设置TTL的条目，注意Filter是在扫描到数据后才执行过滤，你仍然需要消耗对应扫描数据量的读容量，建议使用默认的最终一致读，读容量消耗可以减半
• 扫描过程中必须处理分页逻辑：如果返回结果中存在LastEvaluatedKey，需要将该值作为下一次Scan请求的ExclusiveStartKey，重复请求直到LastEvaluatedKey为空，才算扫完完整的表
• 拿到待更新条目的主键后，优先用BatchWriteItem做批量更新，单次请求最多可处理25条数据，比单条UpdateItem的请求开销低很多
• 8.5亿条的大表建议开启并行Scan，将表拆成多个独立的Segment同时扫描，可以大幅提升扫描速度；同时要主动控制请求速率，避免打满表的吞吐量影响线上业务
• 容错要求高的场景可以把扫描和更新逻辑解耦：扫描到的主键先写入消息队列，再用多个消费者进程异步执行更新操作，避免单进程故障导致任务中断

方案2：用DynamoDB原生批量处理能力（无需自己实现控流逻辑，更适合超大表） #

• 你可以直接使用DynamoDB的全表导出功能，导出时筛选出未携带TTL字段的条目主键，再通过批量导入任务配合自定义转换逻辑统一回填TTL值，整个过程底层会自动适配表的吞吐量上限，不会抢占线上业务的资源，也不用自己写控流、分页逻辑

• TTL字段必须是数字类型，存储的是秒级Unix时间戳，不要写入毫秒级时间戳，否则DynamoDB无法识别生效
• 回填操作前先在测试表验证完整流程，在线上表执行时先按1%、10%的比例逐步放量，确认没有影响业务再全量执行
• 如果你的表开启了DynamoDB Streams，回填TTL的更新操作会生成流记录，要提前通知下游消费逻辑的负责人做好兼容，避免被误判为业务数据更新
• 回填完成后可以随机抽取部分条目调用GetItem校验TTL值是否正确，也可以通过CloudWatch的TTL相关指标确认过期删除逻辑运行正常

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