DynamoDB throttled on a hot partition despite capacity

TL;DR — 你的表整體上有大量未用的 RCU/WCU，但你仍然被限流，因為一個單個分割區索引鍵很熱。每個物理分割槽被設計為每秒最多提供 3,000 讀單元和 1,000 寫單元，無論表有多少容量。堆在一個鍵上的流量耗盡了那一個分割槽。把請求分散到更多不同的分割區索引鍵（寫分片）來修復它。

這是什麼意思

ProvisionedThroughputExceededException: You exceeded your maximum allowed
provisioned throughput for a table or for one or more global secondary indexes.
# ...yet CloudWatch shows consumed capacity well below provisioned.

DynamoDB 把一張表分佈在許多物理分割槽上，而表的容量在它們之間劃分。單個分割槽被設計為每秒最多提供 3,000 讀單元和 1,000 寫單元——在兩種容量模式下都是。如果你的訪問模式把流量集中在一個分割區索引鍵上，那個鍵的分割槽就會觸及它自己的上限並限流——即便全表指標看起來利用不足（錯誤的 ThrottlingReason 欄位，例如 TableReadKeyRangeThroughputExceeded，會指明被觸及的確切限制）。自適應容量有幫助，但它無法拯救一個真正不均衡的鍵。

為什麼會發生

低基數的分割區索引鍵——一個狀態標誌、一個布林值、一個"當前日期"，或者接收大部分流量的單個租戶。
一個爆紅/明星項目——一個熱門的分割區索引鍵（一個走紅的商品、一個熱點使用者）吸引了不成比例的負載。
帶"今天"鍵的時間序列——每次寫入都落在同一個基於日期的分割區索引鍵上。
一個順序或單調的鍵，使寫入聚集在最新的分割槽上。
一個低基數分割區索引鍵的 GSI，它會限流基礎表的寫入。

如何修正

提高鍵的基數。 設計分割區索引鍵使請求分散到許多值上——這是最有效的單一修復方法。
對熱點鍵做寫分片。 追加一個字尾（USER#42#1…USER#42#N），使一個邏輯實體跨越多個分割槽；把讀取扇出到各分片。
給時間序列鍵新增隨機性或一個計算字尾，讓"今天的"寫入不會全部碰撞。
快取熱讀（DAX 或一個應用快取）以卸掉熱點分割槽上的讀壓力。
保持指數退避重試——這個錯誤可重試，且 SDK 預設會退避。
修復低基數的 GSI 鍵——一個被限流的 GSI 會限流基礎表。

想在重新設計時檢查鍵分佈？DynoTable 桌面應用讓你按分割區索引鍵過濾和排序，這樣一個過載的鍵在你重新分片之前就一目瞭然。

在 DynoTable 中檢查大小

查詢熱分割區索引鍵 — 使用 ⌘K 開啟表，按分割區索引鍵排序，然後查詢一個包含比鄰居多得多的項目的鍵。在重新分片之前過濾到該鍵並檢查寫入模式。對 Query Builder 中的寫入分片字尾進行建模，並使用 pricing calculator 估計重試流量。使用 ⌘P 切換設定檔案；參見連線 AWS和安裝。

來源

Best practices for designing partition keys（2026-07-13 驗證）
Troubleshooting throttling in Amazon DynamoDB（2026-07-13 驗證）

常見問題

為什麼當表有空閒容量時DynamoDB會限制我？ 因為單個分割區索引鍵很熱。無論表級容量如何，每個物理分割槽每秒的上限約為 3,000 個讀取單元和 1,000 個寫入單元，因此堆積到一個鍵上的流量會耗盡該分割槽，而表範圍的指標似乎未得到充分利用。

如何修復DynamoDB中的熱分割槽？ 增加分割區索引鍵基數，以便請求分佈在多個值上，使用字尾對熱鍵進行寫入分片，向時間序列鍵新增計算字尾，並快取熱讀取。指數退避重試有助於克服短暫的峰值，但不能修復不平衡的金鑰。

參考資料

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