什么时候不该用 DynamoDB？

当你的工作负载是分析型的，或你的访问模式未知时，跳过 DynamoDB。DynamoDB 专为具有已知、基于键的访问模式的运营型（OLTP）工作负载而构建——它没有连接或聚合函数，临时查询会退化为昂贵的全表扫描。对于 OLAP 报表或不断演变的关系型需求，请选择另一种引擎。

不合适的场景

临时分析与报表（OLAP）——没有 GROUP BY、SUM 或 AVG；每次汇总都是一次扫描，或一个由你自己维护的预计算聚合。变通方案参见聚合指南。
规范化的关系型模式——DynamoDB 有意省略了 JOIN 运算符；AWS 自己的指导是反规范化。如果你的模型确实需要在读取时进行多路连接，关系型引擎更合适——在 DynamoDB vs PostgreSQL 中直接比较。
未知或快速演变的访问模式——你要围绕查询来设计键。当你还叫不出这些查询时，每个新查询都可能带来一次表重设计或一次全表扫描。
全文搜索与丰富查询——参见 DynamoDB 支持全文搜索吗？；搜索应放在搜索索引中。
大对象——项目上限为 400 KB；媒体和文档应放在 S3 中，并在表里放一个指针。

它擅长的地方

上面这份清单的反面恰恰是 DynamoDB 的甜蜜点：高容量的运营型工作负载，具有可预测的基于键的读写，且必须在任意规模下保持个位数毫秒级——购物车、会话、个人资料、游戏状态、物联网事件。何时使用 DynamoDB 指南给出了正面理由，而 DynamoDB vs. 系列对比逐一讲解了各场正面较量。

深入了解

如果你还犹豫不决，接下来阅读何时使用 DynamoDB。已经在用 DynamoDB 却怀念 SQL？DynoTable 可在桌面上对实时表运行 JOIN 和 GROUP BY——而定价计算器会在你投入之前告诉你你的工作负载将花费多少。

参考资料

最后核实于 2026-07-13，依据上方所链接的 AWS 官方文档。

无需控制台即可使用 DynamoDB

DynoTable 是面向 DynamoDB 的快速桌面客户端 —— 浏览表、运行 SQL 风格的查询，并在本地编辑项。