AWS DynamoDB本地二级索引与全局二级索引的区别解析请求

我太懂你看官方文档时的困惑了——那些术语说的太抽象！咱们拿一个电商订单表的实际例子，把这俩索引的区别掰得明明白白。

先设定一个基表场景：
假设我们有个Orders表，基表的分区键是CustomerID（每个客户的订单存在同一个分区里），排序键是OrderTimestamp（每个客户的订单按下单时间排序）。这个基表能帮我们快速查到「某个客户的所有订单，按时间从新到旧排列」。

一、本地二级索引（Local Secondary Index, LSI）：给同一个“组”换个排序方式 #

核心特点 #

必须和基表用同一个分区键，但可以用不同的排序键。

实际例子 #

给Orders表建一个LSI，分区键还是CustomerID，排序键换成OrderTotal（订单总金额）。

这个LSI里的数据是什么样的？

• 每个CustomerID对应的分区，和基表完全对应——比如CustomerID=123的LSI分区，只包含这个客户的所有订单，不会混进其他客户的数据。
• 但在这个分区里，订单是按OrderTotal从高到低（或低到高）排序的，而不是基表的时间排序。

为什么叫“本地”？ #

因为这个索引的范围完全绑定在基表的分区内——它只是给每个基表分区的数据，额外提供了一种排序方式，相当于每个客户的订单数据，除了按时间排，还多了一个按金额排的“本地副本”。

关键限制 #

• 只能在创建基表的时候一起创建，不能事后添加。
• 和基表共享读写容量模式（比如基表是按需付费，LSI也必须是按需）。
• 最多只能建5个。

二、全局二级索引（Global Secondary Index, GSI）：重新给全表数据分组排序 #

核心特点 #

分区键和排序键都可以和基表完全不同，甚至完全独立于基表的分区逻辑。

实际例子 #

给Orders表建一个GSI，分区键是OrderStatus（订单状态：已支付、已发货、已完成等），排序键还是OrderTimestamp。

这个GSI能帮我们做什么？

• 快速查询「所有已发货的订单，按发货时间排序」——这在基表里根本做不到，因为基表是按CustomerID分区的，没法直接把所有不同客户的“已发货”订单聚合到一起。
• 这里的OrderStatus=已发货分区，会包含所有客户的已发货订单，不管他们的CustomerID是什么。

为什么叫“全局”？ #

因为这个索引覆盖了基表的所有分区数据——它相当于把全表的数据，按照新的分区键重新分组，和原表的分区逻辑没有任何绑定关系。

灵活优势 #

• 可以在基表创建完成后随时添加或修改。
• 可以单独设置读写容量模式（比如基表是预留容量，GSI可以用按需）。
• 最多可以建20个。

三、核心区别总结 #

• 分区键关联：LSI必须与基表使用相同的分区键；GSI可使用完全独立的分区键。
• 数据范围：LSI仅包含基表对应分区内的数据；GSI包含基表的全量数据。
• 创建时机：LSI只能随基表一起创建；GSI可在表生命周期内随时添加。
• 资源配置：LSI与基表共享读写容量；GSI拥有独立的读写容量配置。
• 数量限制：LSI最多5个；GSI最多20个。

打个更通俗的比方 #

把基表比作按「家庭（CustomerID）」分组的柜子，每个家庭的物品按「购买时间（OrderTimestamp）」摆放：

• LSI就是每个家庭里，把自己的物品再按「价格（OrderTotal）」重新摆了个小抽屉——只属于这个家庭，不能跨家庭拿东西。
• GSI就是把所有家庭的物品，按「物品类型（OrderStatus）」重新摆了个大柜子——不管哪个家庭的，只要是同一类型都放一起，能直接找到所有同类型物品。

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