DynamoDB 中的 GSI 與 LSI
Global Secondary Index（GSI）與 Local Secondary Index（LSI）都讓你能以一個並非表格鍵的屬性來 Query。它們並不能互換 — 兩者的差異決定了某個模式該選用哪一種。
重要的差異
| GSI | LSI | |
|---|---|---|
| Partition key | 任意屬性 | 與表格相同 |
| Sort key | 任意屬性 | 任意屬性 |
| 建立時機 | 隨時 | 僅限建立表格時 |
| 一致性 | 僅最終一致 | 可強一致 |
| 容量 | 自有 | 共用表格的 |
| 寫入傳播 | 非同步（最終一致） | 同步（原子） |
| 每表格上限 | 20（預設，可調高） | 5（硬限制） |
| 10 GB partition 上限 | 無 | 有（每個 PK） |
經驗法則
- 需要不同的 partition key（例如以
status而非customer查詢訂單）？那你需要 GSI — LSI 無法重新分區。 - 需要在同一個 partition 內有第二種排序順序 — LSI 會保留表格完全相同的 partition key，只換上不同的 sort key — 在一開始就決定好，並要求強一致讀取？那 LSI 適合。
抉擇歸結到一個問題 — 你要更改的是哪一個鍵：
不同的 partition key 強制要用 GSI；同一 partition 上換不同的 sort key，是唯一適合 LSI 的情況。
實務上大多數團隊幾乎只用 GSI：它們可在事後加上、可獨立擴展，且不受每分區 10 GB 限制的約束。讓單一 GSI 的鍵超載以服務多種模式 — 請參閱單一表格設計。
如果你為了消除 Scan 而新增 GSI，請記得它有自己的讀取/寫入容量。用定價計算機估算這筆額外成本，並試用 DynoTable，在決定採用某個索引前先檢查它的投影屬性。