在 DynamoDB 中要怎麼計算項目數？
在 Query 或 Scan 上把 Select 設為 'COUNT'，就能計算符合條件的項目數而不把它們回傳。每次回應最多只涵蓋掃描到的 1 MB，所以你必須用 LastEvaluatedKey 分頁，並把各頁的 Count 加總才會得到完整總數。若只需要一個約略的資料表總數，可以從 DescribeTable 讀 ItemCount。而若你要的是分組計數 — 或對某個欄位做 SUM／AVG — DynoTable 的 SQL Workbench 能把 COUNT 與 GROUP BY 當成一次查詢執行，並替你處理分頁。
精確計算符合的項目
在 Query（針對單一分割區索引鍵）或 Scan（整張資料表）上把 Select 設成 COUNT。回應會回傳 Count 與 ScannedCount，但不含項目資料。如果掃描到的資料超過 1 MB，操作就會停下並回傳 LastEvaluatedKey — 請持續呼叫並累加 Count，直到它不再出現為止。請注意，計數並不比讀取便宜：COUNT 消耗的讀取容量，和把項目回傳出來一模一樣。
Count 與 ScannedCount
Count— 這一頁中符合你的鍵／過濾條件的項目數。ScannedCount— 過濾之前被檢視的項目數。過濾運算式會縮小結果，但不會減少被掃描的量（或它的成本）。
COUNT 不是折扣，實測給你看
「計數和讀取一樣貴」這句話容易斷言，也容易讓人懷疑，所以以下是在一張存有 40 筆、每筆約 3 KB 項目（合計 120,700 位元組）的資料表上的實測，每次呼叫都帶 ReturnConsumedCapacity: 'TOTAL'：
| 請求 | Count | ScannedCount | ConsumedCapacity |
|---|---|---|---|
帶 Select: 'COUNT' 的 Query | 40 | 40 | 15 |
回傳項目的 Query | 40 | 40 | 15 |
Scan、Select: 'COUNT'、過濾條件符合一半 | 20 | 40 | 15 |
要看的是第三列。過濾條件把 Count 砍半、對 ScannedCount 毫無影響，而帳單一分錢也沒動。
15 這個數字是你可以事先算出來的：120,700 位元組向上進位成 30 個 4 KB 讀取單位，再減半，因為除非你另外要求，Query 預設是最終一致的。
便宜的近似值
DescribeTable 會回傳 ItemCount，一個大約每六小時更新一次的全表估計值。它免費又即時取得，但不是即時資料 — 適合儀表板，不適合精確總數。
如果你是對著 DynamoDB Local 測試，有一件事要注意：它會立刻更新 ItemCount。在那裡寫入 40 筆項目再呼叫 DescribeTable，馬上就會回傳 40。真正的服務不會這樣，所以在本機通過的新鮮度邏輯，到了生產環境可能錯上六小時。
用 DynoTable 計數與彙總
原始 API 給了你 COUNT，卻沒有 GROUP BY、SUM 或 AVG — 分組與加總通常得在你的應用程式程式碼裡完成。DynoTable 的 SQL Workbench 把它們補上了：寫 SELECT COUNT(*)、SUM(total) 或一個分組計數，它會替你跑那個分頁迴圈，並隨著頁面串流進來持續修正數字。它仍然是透過 DynamoDB 讀取的，所以同樣的讀取容量成本依舊適用 — 但你寫的是一次查詢而不是一個迴圈，而且你會拿到 API 無法直接回傳的分組與加總結果。
深入了解
請讀在 DynamoDB 中計數、加總與彙總，並用 Expression Builder 建構計數查詢。下載 DynoTable 來對你的資料表執行計數與彙總（COUNT、SUM、GROUP BY）。
參考資料
- Query — Amazon DynamoDB API Reference
- Scan — Amazon DynamoDB API Reference
- TableDescription — Amazon DynamoDB API Reference
最後驗證於 2026-07-13，對照上方連結的 AWS 官方文件。
容量數據已於 2026-07-28 透過 @aws-sdk/client-dynamodb 3.1095.0，對照 DynamoDB Local 3.3.0（amazon/dynamodb-local:latest）重現。DynamoDB Local 不是線上服務；上面提到的 ItemCount 分歧就是兩者不同之處的其中一個。