DynamoDB中联合Primary Partition Key与GSI优化多键查询

你考虑的将多字段组合为GSI排序键的方案完全合理，是DynamoDB多等值条件查询场景下的标准优化方案，可以彻底解决当前FilterExpression扫描冗余数据的问题。

现有方案性能问题 #

你当前的查询逻辑存在明确的性能瓶颈：

• DynamoDB的KeyConditionExpression仅支持对「索引分区键做等值匹配」+「索引排序键做条件匹配」，你提到的“key-condition-expression仅允许配置2个条件”本质是每个索引仅包含分区键、排序键两个可用于KeyCondition的属性，并非只能匹配两个业务字段。
• FilterExpression是在完成索引数据扫描后、结果返回前执行的内存过滤，不会减少实际扫描的数据量，会额外消耗读容量单位（RCU），数据量上涨后查询延迟会明显升高。
• 你当前使用的GSI以RegulationSid为分区键、BundleStatus为排序键，所有同RegulationSid下BundleStatus=APPROVED的记录都会被扫描，无论AccountSid是否匹配，扫描冗余度很高。

推荐优化方案 #

重新设计GSI结构，用组合排序键承载多字段匹配逻辑：

• 选择查询中固定做等值匹配、区分度最高的字段作为GSI分区键，你的场景下可以直接用RegulationSid作为GSI分区键
• 将剩余两个需要做等值匹配的字段AccountSid（即原表主键分区键）、BundleStatus用固定分隔符拼接为单个字符串属性，作为GSI的排序键。分隔符请选择不会出现在字段值中的特殊字符（比如#、|），避免值冲突，示例组合值格式：${AccountSid}#${BundleStatus}

优化后查询示例 #

假设新GSI命名为GSI-RegulationSidAccBundleStatus，排序键属性命名为AccStatusComposite，查询代码如下：

aws dynamodb query \
--table-name bundles \
--index-name GSI-RegulationSidAccBundleStatus \
--key-condition-expression "RegulationSid = :regulationSid AND AccStatusComposite = :compositeSortKey" \
--expression-attribute-values '{
  ":regulationSid": {
    "S": "YYYYYYYYYYYYYYYYYYYYYYYYYYY"
  },
  ":compositeSortKey": {
    "S": "XXXXXXXXXXXXXXXXXXXXXXXXXXX#APPROVED"
  }
}'

这种写法会直接在索引层面精确命中目标记录，不会扫描任何冗余数据，RCU消耗最低，查询速度最快，完全不需要使用FilterExpression。

扩展适配建议 #

• 如果你后续有「仅指定RegulationSid+AccountSid、不指定BundleStatus」的查询需求，拼接组合排序键时把需要做前缀匹配的字段放在前面，查询时用begins_with(AccStatusComposite, :accountSid)作为排序键条件即可，不需要额外新建索引。
• 如果存在其他维度的查询组合，可以根据查询频率评估是否需要新建其他对应结构的GSI，避免单索引承载过多查询模式导致排序键逻辑混乱。

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