本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

利用疏鬆索引

對於資料表中的任何項目，只有在索引鍵屬性存在於項目中時，DynamoDB 才會寫入對應的索引項目。 對於全域次要索引，這表示必須在項目上定義索引分割區索引鍵，如果索引也有排序索引鍵，則該屬性也必須存在。如果某個項目缺少任一索引鍵屬性，則該項目不會出現在索引中。只顯示基礎資料表中項目子集的索引稱為稀疏索引。

稀疏索引在對小型子區塊的資料表進行查詢時很有用。例如，假設您有一個資料表，其中存放您所有的客戶訂單並內含以下索引鍵屬性：

若要追蹤開啟的訂單，您可以在尚未運送的項目訂單中插入名為 isOpen 的屬性。然後，隨著訂單運送時，您可以刪除該屬性。當您在 CustomerId (分割區索引鍵) 和 isOpen (排序索引鍵) 上建立索引時，只有已定義 isOpen 的那些訂單會顯示在其中。當您有上千筆訂單，但只有部分的訂單處於開啟狀態，對開啟訂單查詢索引會比掃描整個資料表快得多且節省更多費用。

相較於使用 isOpen 之類的類型屬性，您可以使用對索引排序順序有用的屬性值。例如，您可以使用設定為訂單下訂日期的 OrderOpenDate 屬性，接著在訂單履行後將其刪除。如此一來，在您查詢稀疏索引時，系統會傳回依訂單下訂的日期所排序的項目。

DynamoDB 中疏鬆索引的範例

全域次要索引依預設是稀疏的。在您建立全域次要索引時，指定一個分割區索引鍵和 (選擇性) 一個排序索引鍵。只有包含必要金鑰屬性的基礎資料表中的項目才會出現在索引中。如果項目缺少索引分割區索引鍵，或定義排序索引鍵時，該項目會從索引中排除。

透過將全域次要索引設計為稀疏，您可以使用低於基礎資料表的寫入輸送量來佈建該索引，同時仍達成優異的效能。

例如，遊戲應用程式可能會追蹤每位使用者的所有比分，但一般來說只需要查詢少數較高的計分。以下設計模式能有效處理這種情況：

在此範例中，Rick 玩了三款遊戲並在其中一款遊戲中達到 Champ 狀態。Padma 玩了四款遊戲並在其中兩款遊戲中達到 Champ 狀態。請注意，Award 屬性僅在使用者獲得獎項時的項目中才會出現。關聯的全域次要索引看起來應如下：

全域次要索引僅包含常受到查詢的高計分，也就是基礎資料表中的小子集項目。