DynamoDB多查询元素建模 多属性查询场景表结构设计方法

基础设计逻辑调整 #

DynamoDB 中不依赖表原始主键的查询完全通过**全局二级索引（GSI）**实现，GSI 拥有独立的分区键、排序键结构，针对查询场景设计 GSI 主键即可避免全表扫描，不需要依赖表的原始主键。
建议优先采用单表设计替代你当前拆分 requests、tickets 两张表的方案，可大幅减少跨表查询开销：

• 表原始分区键（PK）：采用 类型#ID 格式，申请项填 REQUEST#<request_id>，工单项填 TICKET#<ticket_id>
• 表原始排序键（SK）：申请项和 PK 取值一致，工单项填 REQUEST#<关联request_id>

该设计下查询单个申请详情+关联工单，仅需一次 Query 操作：查询 PK = REQUEST#<request_id>，返回结果第一条为申请本身，后续所有项均为关联工单。

多属性检索的GSI设计 #

针对客服侧多属性检索需求，可根据查询频率组合设计多个GSI，以下是适配你场景的参考实现：

GSI1（适配部门+状态开头的组合查询） #

• GSI1 分区键：<用户所属部门>#<工单状态>，将客服最高频的两个过滤维度合并为分区键，精准定位数据分区
• GSI1 排序键：<用户姓氏>#<工单用例>#<用户手机号>，剩余检索字段按查询频率拼接，支持前缀匹配

示例：查询「研发部待处理、姓张、报修类工单」，仅需执行GSI查询：GSI1_PK = 研发部#待处理，GSI1_SK 前缀匹配 张#报修#，全程无扫描。

GSI2（适配手机号维度查询） #

• GSI2 分区键：用户手机号
• GSI2 排序键：<工单状态>#<request_id>

支持直接输入用户手机号查询对应所有工单，不需要知道工单ID或申请ID。

GSI3（适配姓氏维度查询） #

• GSI3 分区键：用户姓氏
• GSI3 排序键：<用户所属部门>#<工单状态>

支持直接按用户姓氏检索所有匹配工单。

优化建议 #

• 单表最多支持20个GSI，完全可以覆盖你当前的检索需求，不需要强行用单个复合键覆盖所有场景
• 可结合稀疏索引特性：仅当项满足特定条件时才填充对应GSI的键值，降低GSI的存储和写入开销
• 如果你坚持保留两张表的设计，直接给tickets表添加上述GSI即可实现非主键查询，不需要调整原有表结构

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