DynamoDB索引配置与多字段关联高效查询问题咨询

你当前的核心查询需求可以通过调整现有全局二级索引（GSI）的配置实现，不需要重构主表，具体配置规则如下：

• 索引分区键设置为Split Test ID，排序键设置为Split Test Value：可直接精准匹配「拆分测试x+参数y」的所有条目，避免查询后再过滤参数值的额外开销，查询效率和你当前使用的仅键索引一致。
• 投影类型选择包含（INCLUDE）：在索引中额外添加你需要返回的关联字段（比如User ID、IP Address、Event Action、Timestamp），查询时可直接从索引读取所有需要的字段，不需要回表查询主表，既不会降低查询效率，也比全投影（ALL）的存储成本低很多。

如果仅需要对同一用户的浏览记录去重计数，可以直接在查询时调用DynamoDB原生的DISTINCT参数指定按User ID去重，不需要自己在业务层做二次计算。

现有表结构不需要做大范围修改，仅两个小优化点可根据实际场景选择：

• 主表主键建议设置为User ID作为分区键，Timestamp作为排序键，匹配事件写入的时序逻辑，不会产生写入热点。
• 如果后续有按时间范围筛选拆分测试数据的需求，可以在上述GSI的排序键后缀拼接Timestamp，调整为Split Test Value#Timestamp，即可支持同个拆分测试、同参数下的时间范围查询，不需要额外新建索引。

你当前选择仅键索引适配计数需求的思路是正确的，DynamoDB索引的核心逻辑就是用额外的写入/存储成本换取查询效率，几个常见的认知误区可以注意：

• 不要为了兼容边缘查询创建过多GSI，每个GSI都会产生独立的写入成本，建议优先通过调整单个GSI的键结构、投影字段覆盖尽可能多的高频查询。
• 所有高频业务查询都必须匹配对应的索引，不要依赖全表扫描实现业务逻辑，全表扫描会消耗大量读容量，且延迟不可控。
• 如果你后续需要处理多维度复杂聚合查询（比如按多字段分组统计、趋势分析等），不要强制用DynamoDB实现，可通过DynamoDB Streams把增量数据同步到专门的分析存储计算即可，你当前的单条件计数需求用GSI完全可以满足。

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