AWS DynamoDB：按日期查询时选GSI还是Scan？

你好，咱们先结合你的场景把核心需求和条件再捋一遍：要查询LastUpdated < 当前时间-2小时的行，99%的数据都不满足这个条件；数据量约10万、日增1000行，写入频率极低；只有单个实体执行读取操作，不需要高吞吐。你纠结的两种方案里，我完全支持你倾向方案二的选择，接下来聊聊社区里的普遍看法，以及你可能没注意到的细节：

先聊聊方案一（Scan）的硬伤 #

虽然并行Scan确实能在数据量变大时提升速度，但成本浪费是无法避免的硬伤——每次Scan都要读取几乎全表的99%不匹配数据，随着数据量增长（比如半年后到48万行），这个成本会线性上升，而且Scan本身会占用主表的读取容量，可能影响其他正常业务的读取（虽然你现在说单个实体读取，但未来如果有业务扩展，这点会变成隐患）。所以方案一长期来看绝对不是最优解。

方案二（带Constant分区键的GSI）的合理性与注意点 #

为什么这个方案完全适配你的场景？ #

你担心的热分区问题，在你的业务规模下几乎可以忽略不计：

• DynamoDB单个分区的写入能力约为1000次/秒，而你的写入频率是：每日新增1000行（每秒≈0.01次）+ 每15分钟更新所有行的LastUpdated（10万行/900秒≈111次/秒）——这个量级远低于单个分区的承载上限，就算未来数据量翻10倍到100万行，更新频率也才1110次/秒，刚好摸到单个分区的阈值，而AWS的分区自动拆分机制会在这时自动扩容，完全不用手动干预。AWS说的“热分区问题已解决”，其实就是指这种动态拆分和负载均衡的能力，你的场景根本到不了需要担心的程度。

几个你可能遗漏的细节 #

1. GSI的成本控制：
   • 新增的Constant列是固定字符串'Foo'，单条数据的存储增量极小，10万行的额外存储成本几乎可以忽略；
   • 查询时只读取匹配条件的行，读取成本是精准的，比Scan划算太多。
2. 更新操作的GSI同步：
   每次更新主表的LastUpdated时，GSI会同步更新对应的条目，这会产生额外的写入操作，但你的更新频率是15分钟一次，这个写入量完全在免费额度或低成本范围内，不用担心。
3. 时间戳的格式规范：
   一定要确保LastUpdated是数字类型的Unix时间戳（毫秒级）或者ISO 8601格式的字符串，这样DynamoDB的排序键比较逻辑才会正常工作。推荐用数字类型，比较效率更高。
4. 一致性的影响：
   GSI是最终一致性的，但你的需求是查询2小时前的数据，就算GSI有几秒的同步延迟，也不会影响旧数据的查询结果，完全符合你的业务要求。
5. 有没有替代方案？
   比如TTL（Time to Live），但TTL是自动删除过期数据，而你的需求是查询而非删除，所以不适用。方案二依然是最优解。

总结 #

方案二完全适配你的当前场景，没有致命缺陷，热分区风险在你的业务规模下可以忽略，长期来看无论是成本还是性能都比方案一优秀太多，放心用就好。

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