最优DynamoDB查询方案探讨：GSI设计及替代方案咨询

背景与需求 #

现有DynamoDB表结构：

employeRemarks可选值：Average, Excellent, Outstanding, BelowAverage, Unworthy

需要检索的记录条件：

• employeRemarks为 Average、Excellent 或 BelowAverage
• joiningDate在时间戳 123000（t1）到 123999（t2）之间

以employeRemarks为分区键、joiningDate为排序键的GSI是否最优？ #

这是当前需求下的最优方案之一，理由如下：

• 该GSI完美匹配查询条件：用employeRemarks做分区键，可针对目标的3个绩效值发起3次高效的Query请求，每个请求指定对应分区键值，再通过joiningDate（排序键）的范围条件BETWEEN t1 AND t2过滤时间区间，全程都是DynamoDB效率最高的索引查询模式，无多余数据扫描。
• 分区键基数合理：employeRemarks仅5个可选值，不会出现分区键基数过大导致的索引膨胀，也不会因基数过小引发热点问题——即使目标的3个绩效值数据量较多，DynamoDB也会自动拆分分区分摊负载。
• 存储与维护成本可控：GSI可选择投影必要字段（如仅投影查询所需列），减少存储开销，日常维护无需额外复杂操作。

其他可探索的方案 #

• 按时间分段的GSI：
  把joiningDate按固定时间粒度（如按天、小时）转换为字符串（比如20240520）作为分区键，joiningDate本身作为排序键。查询时先确定时间区间覆盖的所有分段分区键，发起多次Query后再用过滤条件筛选符合绩效值的记录。但这种方案需要额外处理时间分段，且过滤绩效值会增加计算开销，仅适合时间跨度极大且绩效过滤占比极低的场景。
• 全表扫描+过滤：
  直接对主表执行Scan操作，通过FilterExpression同时过滤绩效值和时间区间。但这种方案会扫描全表数据，效率极低，消耗大量读取容量，仅适合测试环境或数据量极小的表，完全不推荐生产使用。
• 复合分区键GSI：
  将employeRemarks和时间分段组合成分区键（比如Average#202405），joiningDate作为排序键。这种方案适合需要同时按绩效和时间维度分组查询的场景，但针对当前单一时间区间的需求，反而增加了分区键的复杂度，不如第一种方案直接高效。
• PartiQL 查询：
  使用DynamoDB PartiQL语法编写查询语句，例如：

  SELECT * FROM "EmployeeTable" 
  WHERE employeRemarks IN ['Average', 'Excellent', 'BelowAverage'] 
    AND joiningDate BETWEEN 123000 AND 123999
  

  但PartiQL底层会自动判断是否使用可用索引，如果没有前面提到的GSI，依然会走全表扫描；如果有对应GSI，效率和第一种方案一致，只是语法形式不同。

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