在会变化的属性上给 DynamoDB 排序

你围绕某个属性建模排序键，好按它的顺序查询条目——然后这个属性变了。一张工单的状态、一个订单的状态、一个任务的优先级。DynamoDB 抛给你的坑是：你不能就地更新键属性。主键在条目的整个生命周期里都是不可变的。改动一个身为键一部分的值，你就不是在编辑条目——你是在移动它，而 DynamoDB 逼你显式地这么做。

DynamoDB 的排序键能改吗？

不能。排序键是主键的一部分，而 DynamoDB 的键属性是不可变的——UpdateItem 无法编辑分区键或排序键的值，也没有"移动条目"操作。要改动它，就删掉旧条目再放入一个新条目，或者改为把易变的值放在 GSI 排序键上。

• 键属性是不可变的。你无法用 UpdateItem 改动分区键或排序键的值——DynamoDB 没有"移动条目"操作。
• 要改动键值，就删掉旧条目再放入一个新条目——最好放在一个事务里，让它保持原子性。
• 更好的做法：让易变的值离开基表键，改把它放在 GSI 排序键上——GSI 键_可以_变化，因为更新基础条目只会重新传播索引项。
• 只要访问模式允许，就选不会变的排序键（时间戳、不可变的 id）。

问题：你想拿来排序的状态，却一直在变

假设你运营一个技术支持台，想按状态给某个团队的工单排序列出，于是你把状态放进排序键：

PK: TEAM#7   SK: STATUS#open#TICKET#8842

现在这张工单转到了 pending。你想直接用 UpdateItem 把排序键改成 STATUS#pending#TICKET#8842——可 DynamoDB 拒绝任何改动键属性的写入。键是条目的地址；你没法就地编辑这个地址。你选来排序的那个状态，恰恰就是那个坐不住的东西。

方案一：删除后重建（原子地）

如果这个值必须存在基表键里，改动它就意味着移除旧条目、写入新条目：

1. DeleteItem  PK=TEAM#7  SK=STATUS#open#TICKET#8842
2. PutItem     PK=TEAM#7  SK=STATUS#pending#TICKET#8842  (same attributes)

把它放在一个 TransactWriteItems 里，让删除和放入要么都成功、要么都失败——否则两者之间一旦崩溃，工单就会丢失或重复。这样是可行的，但现在每一次状态变化都是两次写入加上一个事务；对偶尔的变化没问题，对频繁的变化就代价高昂了。

方案二：让可变值离开基表键（推荐）

把基表键做成不可变的东西（工单 id），把那个易变、可排序的值放在 GSI 排序键上。

Base:  PK: TICKET#8842   status: "open"   teamId: TEAM#7
GSI:   GSI1PK: TEAM#7    GSI1SK: STATUS#open#TICKET#8842

现在改变状态只是对基础条目的 status 属性做一次普通的 UpdateItem——这是 DynamoDB _允许_的，因为 status 不是基表键。DynamoDB 随后会自动重新传播 GSI 项到它排序后的新位置。一次 API 调用，原子性由它替你处理好——没有事务，没有删除的那套折腾（底层 DynamoDB 仍然会删掉旧索引项并写入新的，所以一次带索引的改动大约耗费 3 个写入单位，而事务式的删除加放入约为 4 个）。

GSI 是最终一致的，并且要额外的存储/写入——但对于一个经常变化的值，那比每次变化都删除后重建要略便宜些（约 3 对 4 个写入单位），也简单得多。

在 DynoTable 中设计键

在 DynamoDB 表达式构建器里为基表读取和 GSI 读取分别构造并预览键条件。

在 DynoTable 里，你接着挑选查询要走哪个索引，看着易变的值在 GSI 上排序、而基础条目保留它不可变的键——两种读取在真实数据上并排呈现。

陷阱与后续步骤

• 绝不要试图用 UpdateItem 改动键属性——它会被拒绝；键值在条目的生命周期里是固定的。
• 如果你必须移动它，就在事务里做删除加放入——绝不要当作两次无防护的写入。
• 对任何你既拿来排序_又_会改动的属性，优先选不可变的基表键加一个 GSI。
• 别忘了 GSI 的最终一致性——重新排序后的项要在短暂的传播延迟之后才出现。
• 相关阅读：排序键策略、GSI vs LSI、事务。

想看看一个可变属性在 GSI 上和基表上分别是怎么排序的？下载 DynoTable，直接探索你的索引。

写入成本：删除并放置 vs GSI 更新

us-east-1 点播中 1 KB 票证项目的粗略 WCU 比较（实际计费遵循AWS舍入规则）：

GSI 这条路径省掉了应用层的编排，也消除了删除与写入之间那个一旦崩溃就会丢行的窗口。 你拿索引读取上的最终一致性去换更简单的写入。

当状态变更每分钟触发很多次时，请在定价计算器里 把你的项大小和更新频率建模一遍。

稀疏 GSI 用于状态排序列表

如果只有 open 票证需要按状态排序的队列，请使用 sparse index：写入GSI1PK = TEAM#7 并 GSI1SK = STATUS#open#...仅当status = open时。当售票截止时，更新时删除或省略 GSI 关键属性 — 该项目从基本排序键上没有删除并放置的索引。这样可以保持索引较小，并避免对你从未列出的已关闭票证建立索引。

首选不可变的基本键

时间戳和不可变 ID (CREATED#2026-06-27T10:00:00Z、TICKET#8842) 当你需要在基表上按时间顺序排列时，创建稳定的基本排序键本身。

编码前设计GSI

映射访问模式 single-table design tool — 输入“列表按团队开票，优先顺序”并检查建议的 GSI1PK / GSI1SK 模板。然后建立关键条件 expression builder 并发出分页使用query builder查询进行集成测试。

状态更改后读取你所写的内容

在UpdateItem之后，对基表的强一致性读取显示立即新status。对 GSI 的查询可能会短暂滞后。 UI 流向重定向到 GSI 排序队列应该容忍陈旧的行或从当精度很重要时，按 id 进行基表。