DynamoDB 按需吞吐量：实测
一张全新的 DynamoDB 按需表能获得多少吞吐量？
一张全新的 表大约能提供每秒 4,130 次写入 —— AWS 文档给出的是 4,000 —— 以及至少每秒 12,700 次最终一致读取。我们在 2026-08-27 针对一张 刚创建几分钟的表测量了这两个数字：在我们施加的每一个超出基线的负载下，写入都 稳定在 4,130 ±2/次；而读取在我们自己的负载生成器耗尽余量之前，从未被限流过。
这两个数字，以及本页的其他一切，都来自对真实服务发出真实请求并计数 —— 而不是 复述文档。方法、原始数据，以及三次失败的尝试，都写在 这篇基准测试实录里；本页则是 这些数字所依托的参考资料。
全新表上的写入上限
我们以 30 秒为一个窗口，对一张从未承接过流量的表逐步加大负载。每个请求都带着 一个约 1 KB、键均匀随机分布的条目 —— 不涉及 ：
| 提供的负载（写入/秒） | 实际达到 | 被限流的请求 |
|---|---|---|
| 1,000 | 1,000 | 0 |
| 2,000 | 2,000 | 0 |
| 3,000 | 3,000 | 0 |
| 4,000 | 4,000 | 0 |
| 5,000 | 4,132 | 25,992 |
| 6,000 | 4,131 | 55,966 |
| 8,000 | 4,134 | 115,922 |
文档中每秒 4,000 次写入的基线成立，上方还有大约 3% 的余量。这个上限相当平稳： 在提供 5,000、6,000 和 8,000 的负载时，实际分别达到了每秒 4,132、4,131 和 4,134 次。越过这个上限时延迟并不会变差 —— 在每一个窗口里，区域内 p50 写入延 迟都保持在 4–5 毫秒。服务不会变慢；它会拒绝请求。
限流实际返回了什么
第一次拒绝发生在每个超出基线的窗口开始后的 0.9–3.8 秒内（提供的速率越高，出 现得越早）。原文如下：
ThrottlingException: Throughput exceeds the current capacity of your table or index. DynamoDB is automatically scaling your table or index so please try again shortly. If exceptions persist, check if you have a hot key: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html有两点需要提前规划。它是一个 HTTP 400，不是 5xx —— 一个只监视 5xx 的重试 策略或告警会完全漏掉按需限流（SDK 默认确实会重试它；参见 ）。而热键提示只是一个默认建议，不是诊断结论 —— 我们的 键是均匀随机的，因此在小规模下，这条消息的第一嫌疑对象是表级上限，而不是你的 键设计。四种不同的限流成因在它们自己的指南里有 讲。
读取上限
读取测试针对另一张预先写入了 1,000 个条目的全新表，以
的 GetItem 发出（约 1 KB，每次 0.5 个读取单位）：
| 提供的负载（读取/秒） | 实际达到 | 被限流的请求 |
|---|---|---|
| 4,000 | 4,000 | 0 |
| 8,000 | 7,941 | 0 |
| 12,000 | 11,119 | 0 |
| 16,000 | 12,762 | 0 |
每个速率下都是零限流。文档中每秒 12,000 次读取的基线成立，而我们没能找到它真 正的边界：在提供每秒 16,000 的负载时，我们八个运行器中有五个在客户端就已经饱 和，所以每秒 12,762 次是我们的测试集群自身的上限 —— 而不是 DynamoDB 的上限。 读取的区域内 p50 延迟为 2–4 毫秒。
持续负载下上限如何增长
AWS 文档说明，按需容量的增长最多能容纳此前峰值的两倍，而在 30 分钟内超过 此前峰值的两倍则可能触发限流。我们对一张表持续施加每秒 8,000 次写入的负载， 持续了连续 34 分钟（四轮 8 分钟的波次，波次之间的间隔不到一分钟），并逐分钟观 察这个上限的变化：
| 波次 | 开始时间 | 逐分钟实际写入/秒 |
|---|---|---|
| 1 | 06:06 UTC | 4,019 → 4,001 → 4,001 → 3,999 → 3,998 → 4,000 → 4,000 → 4,000 |
| 2 | 06:15 UTC | 5,046 → 5,000 → 4,996 → 4,990 → 4,991 → 4,998 → 4,992 → 4,993 |
| 3 | 06:24 UTC | 5,046 → 4,973 → 4,991 → 4,981 → 4,983 → 4,989 → 4,993 → 5,978 |
| 4 | 06:32 UTC | 7,006 → 6,991 → 6,979 → 6,996 → 6,991 → 6,988 → 7,002 → 6,990 |
解读这条时间线：
- 第一个上限很顽固。 在整整前 8 分钟里，这张表都停留在约每秒 4,000 次的 基线上 —— 持续的超额需求在这个窗口内并没有让它移动。
- 增长以约每秒 1,000 次为台阶到来，而不是平滑爬升。 上限在第 9 分钟左右 跳到约每秒 5,000 次，在第 26 分钟左右跳到约每秒 6,000 次，一分钟后又跳到约 每秒 7,000 次，此后一直平稳保持在每秒 7,000 次直到结束。每一个台阶都是在相 邻两分钟之间骤然发生的。三个台阶中有两个出现在我们波次边界附近，因此不足一 分钟的间隔可能与这个增长机制存在交互 —— 我们如实报告观察到的时间点。
- 半小时的持续需求并没有让上限翻倍。 在以每秒 8,000 的负载持续 34 分钟 后，这张表提供了每秒 7,000 次的服务 —— 是起始上限的 1.75 倍，既没达到提供 的速率，也没有实现干净的翻倍。随着容量增长，被限流的请求逐波次下降 （1.9M → 0.5M）。
如果你的上线当天流量会超过一张新表约每秒 4,000 次的上限，请提前给它预热：要 么在活动开始前先跑一遍模拟负载，要么显式设置表的按需最大吞吐量，让 AWS 为它 预置容量。按需与预置对比指南讲了 各个模式各自在什么情况下更划算，而自动扩缩则 是预置模式下，与你在这里看到的自动过程相对应的机制。
两个让我们意外的数字
- 从创建到
ACTIVE的时间相差 3 倍。 同一个区域、同样的 schema 下，一张 全新的按需表在一次运行中 7.4 秒就变为ACTIVE，而在另外两次运行中用了 22 秒。在任何按租户建表或按测试建表的设计里，都要为慢的那种情况预留余量。 - 整个基准测试一共花了 $0.97。 计费的写入为 672,116 次，读取为 108 万 次。那次 34 分钟的持续增长测试又多花了 $12.67。自己测量这项服务，比做错一 次容量决策要便宜得多 —— 你也可以提前用 DynamoDB 定价计算器给类似的工作负载 估价。
范围与方法，坦诚说明
以上一切都只是每个阶段一张表、一天、一个区域（us-east-1）、约 1 KB 的条目、 均匀随机的键。每分区限制（每秒 3,000 个读取单位 / 1,000 个写入单位）低于这里 测量的表级行为，并且有它们自己的失败模式。账户 级配额和硬性服务限制在DynamoDB 限制参考里，用同样 的方法测量得出。如果你每天都要和 DynamoDB 打交道，DynoTable 就 是我们为它打造的桌面客户端 —— 由同一个团队开发，抱着同样的习惯：在重复一个说 法之前，先拿它去对照真实服务核实。