DynamoDB 有多快？
很快。DynamoDB 在任意规模下都提供稳定的个位数毫秒读写延迟。加上内存缓存 DynamoDB Accelerator（DAX），最终一致性读取可以降到微秒级。性能不会随表增长而下降，因为读取是直接定位到分区键而不是扫描，所以延迟不随数据量退化。
它为什么能在规模下保持快
一次 GetItem 或 Query 会对分区键做哈希，直接走到正确的物理分区。它从不扫描整张表，所以不管表里有几千个还是几十亿个项目，响应时间大体上是恒定的。
用 DAX 做微秒级读取
DAX 是一个全托管、与 DynamoDB 兼容的内存缓存，挡在你的表前面。它以微秒级返回最终一致性读取——相比毫秒级最多提升 10 倍——而且没有缓存失效要你管理。它不适合需要强一致性读取的工作负载。
你的用户真正看到的那个数字
个位数毫秒是在 DynamoDB endpoint 处测得的。你的应用体验到的是它加上网络，而网络通常是更大的那一半，而且大得多。
于 2026-07-28 从西班牙的一台机器上测量，每个区域取 9 个样本，记录到各区域 DynamoDB endpoint 的 TCP 握手中位数。这是一次往返，发生在请求的第一个字节被发出之前：
| 区域 | TCP 握手中位数 |
|---|---|
| eu-central-1（法兰克福） | 46.6 ms |
| eu-south-2（西班牙） | 49.1 ms |
| eu-west-1（爱尔兰） | 53.8 ms |
| us-east-1（北弗吉尼亚） | 113.6 ms |
| ap-northeast-1（东京） | 259.5 ms |
一台机器、一个 ISP、一个下午，所以请把它们读作数量级而不是基准测试。其中有两点是普遍成立的。一次跨大西洋往返是它所承载的那次读取的十倍以上，所以在那个距离上，DynamoDB 的延迟在你的总延迟里只是个舍入误差。以及，地理上离这台机器最近的区域并不是从它这里访问最快的那个：eu-south-2 就在西班牙，实测却并不比法兰克福更好，因为决定的是路由，不是距离。
务实的说法是：把计算和表放在一起，胜过你能做的任何 DynamoDB 调优。一个跑在表所在区域的 Lambda 函数只需付上面数字的一个零头；而在另一个大洲的笔记本或 CI 作业，每建立一次连接就要付全额——这也是为什么 SDK 的连接复用比看上去更重要。
什么会拖慢你
- 扫描和过滤——读整张表既慢又贵；请改为设计基于键的访问。
- 热分区——当一个分区键吸走远超其份额的流量时，即使整表容量还很充裕，针对它的请求也会被限流。
让 DynamoDB 保持快的是好的键设计，而不是更多硬件。
深入了解
读一读 query vs scan，并避开热分区。下载 DynoTable 来看清哪些读取跑成了 Query、哪些跑成了 Scan。
参考资料
- Fast NoSQL Key-Value Database — Amazon DynamoDB — AWS
- In-memory acceleration with DynamoDB Accelerator (DAX) — Amazon DynamoDB Developer Guide
- What is Amazon DynamoDB? — Amazon DynamoDB Developer Guide
- Core components of Amazon DynamoDB — Amazon DynamoDB Developer Guide
最后核实于 2026-07-13，依据上方链接的 AWS 官方文档。
延迟数据于 2026-07-28 从西班牙的一台机器上用 curl 测得，每个区域 9 次请求，取针对 https://dynamodb.<region>.amazonaws.com 的 time_connect 减 time_namelookup 的中位数。两次独立运行的结果相差在 3 ms 以内。