DynamoDB排序键设计最佳实践：长排序键是否存在潜在问题？

• 存储与操作成本上升
  长排序键会直接增加单条数据的存储体积，DynamoDB按存储容量计费，长期累积下来的存储成本会明显高于短键。同时，读写操作需要传输更长的键数据，批量操作（如BatchGetItem、BatchWriteItem）中单次请求能处理的条目数会减少，间接提升请求次数和延迟，进一步推高操作成本。

• 查询灵活性严重受限
  你设计的ONBOARDING#{SCHOOL}#{SCHOOL_ADDRESS}#{MAJOR}#{CREATED_AT}这种固定拼接的长键，仅能支持前缀匹配的查询场景。如果后续需要按MAJOR单独筛选、按CREATED_AT做范围查询且不指定完整前缀，只能依赖过滤表达式（过滤是在查询后执行，会浪费读取容量），或者被迫做全表扫描。若要调整查询维度（比如先按专业找用户再看所属学校），这种结构完全无法支持，最终还是得依赖GSI，违背了减少GSI的初衷。

• 维护与扩展性风险
  长键包含多个业务字段，一旦某个字段的格式需要变更（如学校名称规范调整、地址格式优化），你需要更新所有相关条目的排序键，这会产生大量写操作，不仅成本高，还可能引发数据一致性问题。如果后续新增业务字段需要加入排序键，键长会快速逼近DynamoDB的键大小限制（PK+SK最大400KB），届时只能重构表结构，反而增加了架构复杂度。

• 索引效率被削弱
  即便现在不使用GSI，未来若需创建索引，长排序键会导致索引条目体积增大，既提升索引的存储成本，也会降低索引的读写性能。

小建议 #

如果想减少GSI依赖，可以将高频查询维度（如SCHOOL）作为排序键前缀，把SCHOOL_ADDRESS、MAJOR这类非高频字段存为普通属性，通过过滤表达式处理非核心查询；或者采用分层复合键设计，比如ONBOARDING#{SCHOOL}#{CREATED_AT}，既保留按学校高效查询的能力，又避免键过长的问题。

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