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

# 3- 超過帳戶限制
<a name="throttling-account-limit-exceeded-mitigation"></a>

隨需資料表無需管理佈建容量層級，但 DynamoDB 仍會強制執行帳戶層級輸送量限制，以防止執行失控並確保所有客戶的資源公平使用。這些每資料表帳戶限制作為可調整的保護機制，針對每個帳戶與區域組合進行設定。當您的讀取或寫入耗用率超出這些限制時，DynamoDB 會在限流例外狀況中回傳 `AccountLimitExceeded` 限流原因類型。若資料表未設定自訂最大輸送量，則會自動套用預設的每資料表帳戶限制。您可選擇設定最大輸送量以提升成本控制與可預測性；若應用程式需求超出預設限制，則可透過 [Amazon DynamoDB 中的配額](ServiceQuotas.md) 主控台請求提高配額。

## 超出帳戶限制的緩解措施
<a name="throttling-account-limit-exceeded"></a>

本節說明帳戶限制導致限流的解析與解決指引。使用本指南前，請先從應用程式的例外狀況處理中確認具體的限流原因，並確定受影響資源的 Amazon Resource Name (ARN)。如需了解如何擷取限流原因與識別受限流的資源，請參閱 [DynamoDB 限流診斷架構](throttling-diagnosing-workflow.md#throttling-diagnosing)。

在分析特定限流情境前，請先判斷是否確實需要採取行動：
+ **評估效能影響：**檢查應用程式在發生限流時是否仍符合效能需求。許多應用程式即使在達到或接近帳戶限制時仍能正常運作，特別是在大量操作或資料移轉期間。
+ **檢視限流模式：**若限流為間歇性，且應用程式能有效處理重試，則目前限制可能已足以支撐工作負載。

若應用程式即使偶爾達到帳戶限制仍能穩定運作，您可選擇持續監控而非立即進行變更。

若您判斷限流導致效能或可靠性問題，請從下列限流原因中選擇，以查看建議的緩解方案：
+ [TableReadAccountLimitExceeded](#throttling-table-read-account-limit) 
+ [TableWriteAccountLimitExceeded](#throttling-table-write-account-limit)
+ [IndexReadAccountLimitExceeded](#throttling-index-read-account-limit) 
+ [IndexWriteAccountLimitExceeded](#throttling-index-write-account-limit) 

### TableReadAccountLimitExceeded
<a name="throttling-table-read-account-limit"></a>

**發生這種情況時**  
您的資料表讀取耗用情形已超出您所在區域的帳戶層級每資料表讀取輸送量配額。可透過 [常見診斷與監控](#account-limit-exceeded-diagnosis-monitoring) 監控 CloudWatch 指標，以分析限流事件。

**解決方法**  
請依下列步驟解決此限流問題：
+ **請求配額增加：**

  請求提高每資料表讀取輸送量限制 (Quota 程式碼 L-CF0CBE56)。如需提交請求的詳細步驟，請參閱[請求每資料表配額增加](#account-limit-request-per-table-quota)。

### TableWriteAccountLimitExceeded
<a name="throttling-table-write-account-limit"></a>

**發生這種情況時**  
您的資料表寫入耗用情形已超出您所在區域的帳戶層級每資料表寫入輸送量配額。可透過 [常見診斷與監控](#account-limit-exceeded-diagnosis-monitoring) 監控 CloudWatch 指標，以分析限流事件。

**解決方法**  
請依下列步驟解決此限流問題：
+ **請求配額增加：**請求提高每資料表寫入輸送量限制 (Quota 程式碼 L-AB614373)。如需提交請求的詳細步驟，請參閱[請求每資料表配額增加](#account-limit-request-per-table-quota)。

### IndexReadAccountLimitExceeded
<a name="throttling-index-read-account-limit"></a>

**發生這種情況時**  
針對全域次要索引 (GSI) 的讀取操作耗用的輸送量，超出您帳戶在目前 AWS 區域允許的每資料表讀取配額。帳戶層級的每資料表讀取輸送量配額會整體套用至該資料表及其所有 GSI。可透過 [常見診斷與監控](#account-limit-exceeded-diagnosis-monitoring) 監控 CloudWatch 指標，以分析限流事件。

**解決方法**  
請依帳戶容量分佈選擇合適的解決方法：
+ **請求配額增加：**請求提高每資料表讀取輸送量限制 (Quota 程式碼 L-CF0CBE56)。如需提交請求的詳細步驟，請參閱[請求每資料表配額增加](#account-limit-request-per-table-quota)。
+ **最佳化 GSI 耗用情形：**[檢視 GSI 設計與查詢模式](#account-limit-optimize-gsi-projections)，以減少不必要的讀取容量耗用。

### IndexWriteAccountLimitExceeded
<a name="throttling-index-write-account-limit"></a>

**發生這種情況時**  
對基底資料表的寫入操作會產生對應的 GSI 更新，這些 GSI 總共超過您 AWS 區域的帳戶層級每個資料表寫入輸送量配額。每次將包含 GSI 索引屬性的項目寫入基礎資料表時，系統都會觸發對應的 GSI 寫入操作。這些合併的寫入操作會計入您的每資料表寫入輸送量配額。您可以在 [常見診斷與監控](#account-limit-exceeded-diagnosis-monitoring) 中監控 CloudWatch 指標，以分析這些限流事件的模式與時間，並識別造成過度 GSI 寫入的操作。

**解決方法**  
請依帳戶容量分佈選擇合適的解決方法：
+ **請求配額增加：**請求提高[每個資料表的寫入輸送量上限](#account-limit-request-per-table-quota) (Quota 程式碼 L-AB614373)，以因應基礎資料表操作所產生的更高 GSI 寫入流量。每個資料表的寫入輸送量配額會套用至整個資料表，包括其所有的 GSI。如需提交請求的詳細步驟，請參閱[請求每資料表配額增加](#account-limit-request-per-table-quota)。
+ **最佳化 GSI 投影：**[檢視 GSI 投影與設計](#account-limit-optimize-gsi-projections)，以降低 GSI 寫入量。

## 常見診斷與監控
<a name="account-limit-exceeded-diagnosis-monitoring"></a>

疑難排解帳戶限制超限限流事件時，多項 CloudWatch 指標可協助判斷您是達到每資料表限制或整體帳戶限制，並協助分析容量分佈模式。

**主要 CloudWatch 指標**  
監控以下關鍵指標，以診斷帳戶限制導致的限流：
+ **帳戶限制限流事件：**[https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadAccountLimitThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadAccountLimitThrottleEvents) 與 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteAccountLimitThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteAccountLimitThrottleEvents) 會追蹤因帳戶層級限制而遭限流的請求；[https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#ReadThrottleEvents) 與 [https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/metrics-dimensions.html#WriteThrottleEvents) 則會追蹤任何讀取或寫入請求何時超出佈建容量。
+ **依資源的容量耗用情形：**每個資料表與 GSI 的 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedReadCapacityUnits) 和 [https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html#ConsumedWriteCapacityUnits) 指標會顯示各自的資源使用情況。
+ **全帳戶耗用：**使用 CloudWatch 的指標數學運算式，將所有資料表與 GSI 的耗用容量加總，以監控帳戶總體用量。

## 解決步驟
<a name="account-limit-throttling-resolution-procedures"></a>

### 請求每個資料表配額增加
<a name="account-limit-request-per-table-quota"></a>

如果您的應用程式必須在超出目前每個資料表輸送量上限的情況下運作，請依下列程序提交配額增加申請。您 AWS 帳戶中的每個 DynamoDB 資料表 （連同其所有相關聯的 GSIs) 都受到特定區域內這些輸送量配額的約束。這些配額代表每個資料表及其 GSI 可共同使用的最大讀取或寫入容量，並會獨立套用於各資料表，而非以整個帳戶所有資料表的總量計算。

您也可以選擇為每個資料表或每個 GSI 設定最大隨需輸送量，以限制其最高可用容量。

1. 識別需要提高的特定配額：
   + **每個資料表讀取輸送量限制** (配額代碼 L-CF0CBE56)：每個資料表的預設值為 40,000 RCUs
   + **每個資料表寫入輸送量限制** (配額代碼 L-AB614373)：每個資料表的預設值為 40,000 WCUs

1. 使用 [AWS Service Quotas 主控台](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html)提出配額提高請求：
   + 在 Service Quotas 主控台中導覽至 DynamoDB 服務
   + 透過配額代碼尋找對應的配額
   + 根據預期尖峰使用量提出配額提高請求

1. 說明提高配額的理由，包括：
   + 目前的使用模式與尖峰流量需求
   + 提高容量的業務理由
   + 提高容量所需的時間規劃

**注意**  
配額提高的處理通常需要 24 至 48 小時。請相應規劃您的請求，並在等待核准期間考慮暫時的應變策略。

### 最佳化 GSI 投影與設計
<a name="account-limit-optimize-gsi-projections"></a>

透過最佳化全域次要索引 (GSI) 的投影與設計，降低容量消耗並提升效能。

**選擇性投影策略**  
若查詢僅需存取少數屬性，則在基礎資料表項目變更時，只投影這些屬性能減少寫入 GSI 的資料量。如需投影類型的詳細資訊，請參閱[全域次要索引投影](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/GSI.html#GSI.Projections)。

1. 分析查詢模式：檢視應用程式的查詢模式，以確認哪些屬性實際透過 GSI 存取。

1. 使用選擇性投影：僅投影查詢實際需要的屬性，以減少寫入量。

1. 考慮使用 `KEYS_ONLY`：若查詢僅需鍵屬性，可使用 `KEYS_ONLY` 投影以將寫入量降至最低。

1. 平衡讀寫取捨：減少投影屬性可降低寫入容量耗用，但可能需要額外的基礎資料表讀取。

**稀疏 GSI 實作**  
稀疏 GSI 僅包含具有索引屬性的項目，而非基礎資料表的所有項目。此設計可降低分割區密度，並在頻繁查詢特定資料子集時提升效能。

1. 設計僅包含特定屬性值項目的 GSI。

1. 僅在需建立索引的項目上設定 GSI 分割區索引鍵屬性，以實作條件式索引。

1. 在稀疏 GSI 中使用複合索引鍵 (例如 status\#timestamp)，以進一步分散索引項目子集的流量。

如需實作這些策略的詳細資訊，請參閱[在 DynamoDB 中使用次要索引的最佳實務](https://docs.aws.amazon.com//amazondynamodb/latest/developerguide/bp-indexes.html)。