在 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 个四千字节读取单元，再因为 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 中的计数、求和与聚合，并用表达式构建器构建计数查询。下载 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 针对 DynamoDB Local 3.3.0（amazon/dynamodb-local:latest）通过 @aws-sdk/client-dynamodb 3.1095.0 复现。DynamoDB Local 不是真实服务；上文记下的 ItemCount 分歧就是它们不同的一处。