NoSQL单表设计实践：DynamoDB如何高效实现按课程状态筛选学生注册课程

核心原则：易变更的动态属性绝对不能嵌入复合主键结构，否则会触发大规模写放大的极高成本，完全违背单表设计的效率初衷

结合当前的学生-课程注册业务模型，有三个生产环境验证过的可行实现路径：

1. 应用层后置筛选（零结构改造成本） #

这是最省事的实现方式，完全不需要调整现有表结构：

• 沿用原有单表查询逻辑：指定分区键为Student#002，匹配排序键前缀Class#，一次性拉取该学生所有的注册关联记录，拿到所有关联的课程ID清单
• 用BatchGetItem批量拉取对应课程的CLASS类型实体记录，读取每条记录的Status属性
• 在应用内存侧过滤出Status = OPEN的课程列表
• 适用场景：单个学生注册的课程数量通常在几十到上百的量级，全量拉取的读成本极低，全程没有额外写操作开销，不需要改动现有主键设计。

2. 全局二级索引（GSI）适配查询需求 #

如果对查询延迟、筛选效率有更高要求，可以通过GSI实现查询解耦，不需要修改原有主表的主键结构：

• 设计匹配需求的GSI结构：将学生ID设置为GSI的分区键，将课程状态设置为GSI的排序键，同时投影关联的课程ID作为非键属性
• 写入逻辑调整：写入注册记录时，同步往GSI写入对应课程的当前状态值；当课程状态发生变更时，仅需更新主表上对应课程实体的单条记录，再通过DynamoDB Streams自动同步GSI中关联条目的状态值即可
• 查询逻辑：直接走GSI查询，指定分区键为目标学生ID，排序键匹配OPEN，单次查询就能拿到该学生所有注册的开放状态课程，不需要全量拉取后二次过滤
• 成本优势：课程状态变更时只需要更新GSI条目的普通属性，不需要做跨记录的主键删除、重建操作，相比把状态嵌入主键的方案，写操作成本下降一个数量级以上。

3. 分层缓存降低筛选开销 #

如果不想引入GSI的额外成本，可以配合应用层缓存减少二次查询的开销：

• 保持现有注册记录的排序键为固定的Class#ID结构，课程状态变更时完全不需要触碰关联的注册记录
• 应用层本地缓存所有课程的实时状态（缓存过期时间设置为课程状态的变更容忍度，比如1分钟）
• 查询学生注册的开放课程时，先拉取学生的所有注册课程ID，直接匹配本地缓存的课程状态做筛选，省去批量读课程实体的网络开销

明确的反模式提醒：绝对不要把课程状态这类高频变更的属性嵌入排序键。一旦课程状态从OPEN变为CLOSED，就需要删除所有关联的旧注册记录、再新建带新状态前缀的注册记录。在单课程关联上万学生的场景下，单次状态变更的写操作成本会高到完全不可接受，这也是单表设计实践中明确要规避的反模式。

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