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 官方文档。