什么时候不该用 DynamoDB？

当你的工作负载是分析型的，或者访问模式还未知时，别用 DynamoDB。DynamoDB 是为访问模式已知、基于键的操作型（OLTP）工作负载专门打造的——它没有连接，也没有聚合函数，而即席查询会退化成昂贵的全表扫描。要做 OLAP 报表或者关系型需求还在演进，就挑别的引擎。

不合适的场景

即席分析与报表（OLAP）——没有 GROUP BY、SUM 或 AVG；每一次汇总要么是一次扫描，要么是一个你自己维护的预计算聚合值。变通办法见聚合指南。
规范化的关系型模式——DynamoDB 刻意省略了 JOIN 运算符；AWS 自己的建议就是做反规范化。
访问模式未知或变化很快——你是围着查询来设计键的。当你还说不出那些查询时，每来一个新查询都可能逼你重新设计表，或者逼出一次全表扫描。
全文搜索和丰富查询——参见 DynamoDB 支持全文搜索吗？；搜索该放在搜索索引里。
大对象——项目上限是 400 KB；媒体和文档该放在 S3 里，表里只留一个指针。

那次汇总：先被拒绝，然后被标价

分析场景不合适，这不是口味问题。用 PartiQL 向 DynamoDB 要一个分组计数，语句在读到任何东西之前就被拒了：

SELECT status, COUNT(*) FROM "orders" GROUP BY status

ValidationException: Unsupported clause: GROUP BY
HTTP 400

把分组去掉、只要一个普通总数，它会更早一步、在解析器里就失败：

SELECT COUNT(*) FROM "orders"

ValidationException: Unexpected path component at 1:8:5
HTTP 400

COUNT 在这个方言里压根不是函数，所以解析器把它读成一条属性路径，然后在括号处放弃。

剩下的就是你自己写的那次 Scan，而它是有价的。把一张 50 GB 的表从头读到尾要花 6,553,600 个最终一致性读取单元，也就是按 4 KB 为单位计的累计扫描大小再减半。在 us-east-1 按需模式下，那是 $0.82。

每小时刷新这一个数字，一个月就是 $598。在写入时顺手维护那个计数器，或者导出到一个分析存储里，才是更便宜的答案，而这两件事 DynamoDB 都不会替你做。

它擅长的地方

反过来的那份清单恰恰是 DynamoDB 的甜点区：高吞吐的操作型工作负载，读写基于可预测的键，并且在任何规模下都必须保持个位数毫秒——购物车、会话、档案、游戏状态、IoT 事件。什么时候该用 DynamoDB 的指南讲的是正面的那一半。

深入了解

如果你还在犹豫，接着读什么时候该用 DynamoDB。已经在用 DynamoDB 但怀念 SQL？DynoTable 能在桌面端针对实时表运行 JOIN 和 GROUP BY——而定价计算器会在你做决定之前告诉你，你的工作负载要花多少钱。

参考资料

最后核实于 2026-07-13，依据上方链接的 AWS 官方文档。400 KB 这个数字已于 2026-07-28 重新确认；AWS 已把它从服务配额页面挪进了 Constraints.html。

2026-07-28 在 Node v24.18.0 上通过 @aws-sdk/client-dynamodb 3.1095.0 针对 DynamoDB Local 3.3.0 复现；两条 ValidationException 消息均为原样照录。Scan 成本依据我们同步的 AWS 定价表中的 us-east-1 费率算出。