如何用DynamoDB secondary index统计近24小时A类条目数

适配场景的索引设计方案 #

推荐使用全局二级索引（GSI），键值搭配如下：

• 索引分区键：复用现有字段item（固定枚举值A/B）
• 索引排序键：复用现有字段entry time（录入时间）

具体查询实现逻辑 #

1. 提前计算查询时间范围：获取当前时间戳作为时间上限，向前回溯24小时得到时间范围的下限
2. 对上述GSI发起Query请求，设置两个匹配条件：
   • 分区键精确匹配：item = "A"
   • 排序键范围匹配：entry time 介于计算得到的24小时窗口上下限之间
3. DynamoDB的Query接口会直接返回符合条件的条目总计数，不需要拉取全量条目再做本地统计，直接读取接口返回的Count字段值即可得到最终结果。

关键注意事项 #

• 禁止使用本地二级索引（LSI）：LSI的分区键必须和原表的主键（即这里的id）完全一致，无法实现跨id的按item类型聚合查询，完全不匹配当前场景。
• 时间字段存储格式必须支持排序：建议直接存储Unix时间戳、标准化ISO8601格式字符串这类可逐字节排序的时间值，避免用自由格式的时间文本，否则排序键的范围筛选会直接失效。
• 优化查询成本：如果只需要统计数值、不需要返回具体条目内容，可以将Query的投影属性设为空，仅获取计数字段，可大幅降低读容量消耗。
• 注意同步延迟：GSI的数据是异步同步的，常规延迟在几百毫秒到数秒级别，对实时性要求极高的统计场景需要预留对应容错窗口。
• 方案成本对比：如果不用GSI，直接对原表做全表扫描加条件过滤，会因为无效条目占用读容量，整体查询成本比上述GSI方案高1~2个数量级，不适合作为常态化统计方案。

很多人容易因为没找到直接匹配的示例就误以为二级索引不支持这个场景，实际上这个配置是这类查询的最优解——多数教程只会演示GSI的通用查询能力，不会把“24小时窗口内A类条目计数”这么细分的场景单独列成示例，所以检索匹配资料的门槛会比预期高。

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