DynamoDB 有多快？
很快。DynamoDB 在任何規模下都提供一致的個位數毫秒讀寫延遲。加上記憶體內快取 DynamoDB Accelerator（DAX），最終一致讀取可以縮短到微秒等級。效能不會隨資料表變大而下滑，因為讀取是直接鎖定分割區索引鍵而不是掃描，所以延遲不會隨資料量惡化。
為什麼它在大規模下仍然很快
一次 GetItem 或 Query 會對分割區索引鍵做雜湊，然後直接走到正確的實體分割區。它從不掃描整張資料表，所以不管資料表裡有幾千筆還是幾十億筆項目，回應時間大致固定。
用 DAX 達成微秒讀取
DAX 是一個全受管、與 DynamoDB 相容的記憶體內快取，擋在你的資料表前面。它以微秒回傳最終一致讀取 — 相較於毫秒最多可提升 10 倍 — 而且不需要你管理快取失效。它不適合需要強一致讀取的工作負載。
你的使用者真正看到的那個數字
個位數毫秒是在 DynamoDB 端點上量到的。你的應用程式體驗到的是那個數字再加上網路，而網路通常是其中大得多的那一半。
以下是 2026-07-28 從西班牙的一台機器量測的結果，每個區域九次取樣，取到各區域 DynamoDB 端點的 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 與 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 量測，每個區域九次請求，對 https://dynamodb.<region>.amazonaws.com 回報 time_connect 減去 time_namelookup 的中位數。兩次獨立執行的結果差距在 3 ms 以內。