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

利用疏鬆索引

針對資料表中的任何項目，DynamoDB 在索引的排序索引鍵值存在於項目中時，才會寫入相對應的索引項目。若排序索引鍵並未出現在每個資料表項目中，或分割區索引鍵並未出現於項目中，則該索引便可稱為疏鬆。

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

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

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

DynamoDB 中疏鬆索引的範例

全域次要索引依預設是稀疏的。在您建立全域次要索引時，指定一個分割區索引鍵和 (選擇性) 一個排序索引鍵。只有在基本資料表中含有那些屬性的項目會出現在索引中。

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

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

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

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