DynamoDB LSI item collection 10 GB limit

TL;DR — 在一張帶本地次要索引的表上，一個_項目集合_——每個共享一個分割區索引鍵的項目，加上它們的 LSI 投影——合計最多 10 GB。只有 LSI 表才有這個上限，因為每個項目集合必須容納在單個分割槽上。一次會把集合推過 10 GB 的寫入會以 ItemCollectionSizeLimitExceededException 失敗。監控 ItemCollectionMetrics、重新分片增長的鍵，或者用 GSI（它沒有這樣的限制）替換 LSI。

這是什麼意思

ItemCollectionSizeLimitExceededException: Collection size exceeded.

一個項目集合是表及其所有 LSI 中具有相同分割區索引鍵值的所有項目的集合。當一張表有 LSI 時，DynamoDB 把每個項目集合儲存在單個分割槽上，因此集合受該分割槽 10 GB 容量的限制。沒有 LSI 的表沒有逐集合的大小限制（GSI 也沒有）。所以這個錯誤是一個訊號：某個分割區索引鍵的資料在一個 LSI 下無界地增長了。它是一個 HTTP 400；AWS 把它列為可重試，但重試只有在集合縮小後才會成功——讀取和縮減大小的寫入（刪除、修剪屬性）仍然被允許。

為什麼會發生

一個無界的分割區索引鍵——一個大租戶、一個繁忙的使用者，或一個僅追加的日誌都在一個鍵下寫入。
LSI 本身——10 GB 上限_只_因為表有一個 LSI 才存在（在表建立時建立且不可移除）。
寬的 LSI 投影——把許多屬性投影進 LSI 會更快地膨脹集合。
穩步增長，悄悄逼近 10 GB，直到一次寫入最終越過它。

如何修正

重新分片分割區索引鍵。 把過大的實體跨多個鍵拆分（TENANT#42#1、TENANT#42#2……），使得沒有單個集合無界地增長。
用 GSI 替換 LSI。 GSI 有它們自己的分割區索引鍵且沒有項目集合大小限制——對大多數訪問模式而言，GSI 更合適，而且它可以在表建立後新增/移除（LSI 不行）。
修剪 LSI 投影——如果你必須保留 LSI，就投影更少的屬性（KEYS_ONLY/INCLUDE）以減緩集合增長。
把冷項目歸檔出熱集合到另一張表或 S3。
在撞牆之前監控。 在寫入（PutItem、UpdateItem、DeleteItem、BatchWriteItem、TransactWriteItems）上設定 ReturnItemCollectionMetrics: SIZE；DynamoDB 會返回一個 SizeEstimateRangeGB 估計值，AWS 建議在一個使用者定義的閾值（例如 8 GB）上告警，讓你在 10 GB 之前採取行動。

在重做鍵和索引以擺脫 LSI 限制？DynoTable 桌面應用讓你按分割區索引鍵過濾，這樣你就能在重新分片之前看到哪個集合過大了。

從 DynoTable

找到接近 10 GB 的分割區索引鍵 — 使用 ⌘K 開啟表，按分割區索引鍵排序，並對每個集合的項目進行計數。當廣泛的 LSI 預測導致館藏膨脹時，item size calculator 估計會出現增長。將 LSI 寫入成本與 GSI 遷移與 pricing calculator 進行比較。使用 ⌘P 切換設定檔案；參見連線 AWS和安裝。

來源

Local secondary indexes（2026-07-13 驗證）
PutItem — Amazon DynamoDB API Reference（2026-07-13 驗證）

參考資料

最後核實於 2026-07-13，依據上方連結的 AWS 官方文件。