更好的 AWS DynamoDB 控制台替代方案

AWS DynamoDB 控制台给你一个表列表和一个基础的项浏览器。一旦你需要过滤一张大表、翻阅结果、导出超过一页，或运行任何类似聚合的东西，它就会碍事。DynoTable 是一款围绕一个 SQL Workbench 构建的桌面 DynamoDB 客户端，它在 DynamoDB 的访问模式规则内运行 JOIN、GROUP BY 和聚合——也就是控制台的 PartiQL 编辑器无法表达的查询。本页面是对控制台做不到什么、以及专用客户端增加了什么，一份有事实、有日期的审视。DynoTable 读取你标准的 AWS 凭证链并指向你账户中的同样的表，所以没有什么要迁移。

功能	DynoTable	AWS DynamoDB Console
SQL JOINs, GROUP BY & aggregates	支持	否
Aggregate functions (COUNT / SUM / AVG)	支持	SIZE only
Filter without billing the full scan	Same Query/Scan ops	Post-scan filter
Export full result to CSV	支持	One page at a time
Auto-paginating result grid	支持	Manual, 1 MB at a time
Multiple tabs & saved queries	支持	否
Install	Desktop app	None
Pricing	Paid	Free

AWS 控制台缺什么

控制台的项浏览器是 DynamoDB API 之上的一层薄包装，所以它继承了 API 的粗糙边缘，却没有抹平任何一处：

过滤是扫描后的，不是真正的查询。 过滤表达式"在 Scan 完成之后、结果返回之前应用"，所以一次 Scan "无论是否存在过滤表达式都消耗相同数量的读容量" （AWS 文档）。你为读取整页付费，然后大部分被丢弃。 query vs scan 指南讲解了这对成本为什么重要。
分页是手动的，每次 1 MB。 "单次 Scan 请求最多可检索 1 MB 数据"，且"没有 LastEvaluatedKey 是知道你已到达结果集末尾的唯一方式" （AWS 文档）。在控制台里那意味着一页接一页地点击来走完一张表——参见分页指南了解游标在底层如何工作。
CSV 导出一次只能一页。 AWS 自己的 CSV 导出文档直白地指出："你可以一次一页地把结果导出到 CSV 文件。如果有多页结果，你必须逐页导出" （AWS 文档）。那一页记录的是 NoSQL Workbench 的操作构建器；Web 控制台的 "Explore items"视图以同样方式导出所显示的页——完整导出意味着手动翻页和下载。
没有聚合。 DynamoDB 的 PartiQL 只列出一个聚合函数—— SIZE——并指出"任何不在此列表中的 SQL 函数当前不受支持" （AWS 文档）。控制台编辑器中没有 COUNT、SUM 或 AVG。

开发者每天都会撞上的控制台局限

任务	AWS DynamoDB 控制台	DynoTable
过滤一张大表	过滤器在扫描后应用；仍计费整次读取（文档）	在同样的 Query/Scan 操作上的可视化过滤/键条件构建器
翻阅结果	手动，每次 1 MB / `LastEvaluatedKey`（文档）	持续滚动的结果网格，为你获取各页
导出为 CSV	逐页：NoSQL Workbench "逐页"导出（AWS 文档）；控制台的 Explore-items 导出只覆盖屏幕上的页	导出查询/扫描结果而无需逐页点击
`COUNT` / `SUM` / `AVG`	不支持——只有 `SIZE`（文档）	SQL Workbench 中的 `GROUP BY` + 聚合
JOIN 两张表	不支持——PartiQL `SELECT` 是单表的（文档）	规划到真正 Query/Scan 操作的 `INNER`/`LEFT JOIN`

你能在控制台里用 SQL 查询 DynamoDB 吗？

只能用 PartiQL 暴露的那个 SQL 风味子集。控制台有一个内置的 PartiQL 编辑器（在左侧导航窗格中），能运行 PartiQL 语句（AWS 文档），而 PartiQL 的 SELECT 语法刻意狭窄：

SELECT expression [, ...]
FROM table[.index]
[ WHERE condition ]
[ ORDER BY key [DESC|ASC], ... ]

（AWS 文档。）一张表、一个可选的 WHERE、可选的排序——没有 JOIN、没有 GROUP BY、也没有 SIZE 之外的聚合。那忠实地暴露了 DynamoDB 的单表访问模型，但它意味着分析型问题在控制台里没法做。 PartiQL vs SQL 指南详述了该语法止步于何处，而 PartiQL 示例指南有可复制粘贴的语句，展示它能做什么。

DynoTable 的 SQL Workbench 把更丰富的 SQL——INNER/LEFT JOIN、GROUP BY、 COUNT、SUM 等——在客户端向下编译为 DynamoDB 真正的 Query/Scan 操作。你写关系型的 SQL；DynoTable 针对你的键和 GSI 规划它，所以它停留在 DynamoDB 的访问模式规则内而非假装表是关系型数据库。如果你撞上了控制台的 PartiQL 编辑器止步的墙，SQL for DynamoDB 指南解释了什么可行什么不可行，DynamoDB JOIN 指南展示了 Workbench 如何连接两张表，而 GROUP BY 指南涵盖了在没有 GROUP BY 子句的情况下聚合。

如何在不逐页点击的情况下把 DynamoDB 表导出为 CSV

AWS 的原生 CSV 导出是逐页的。对于 NoSQL Workbench 的操作构建器，文档很明确：你"可以一次一页地把结果导出到 CSV 文件" 且"必须逐页导出" （AWS 文档）。 Web 控制台的 Explore items 视图以同样方式面向页——它一次扫描一页结果，你导出眼前的行——所以一张大表的完整导出仍然意味着手动过滤、翻页和下载。专用客户端一次性导出一个查询或扫描的整个结果集，包括过滤后的视图。更长篇的选项——AWS CLI、S3 导出、脚本—— 在把 DynamoDB 导出为 CSV 指南中涵盖。有一个值得提前知道的坑：DynamoDB 的底层 API 用类型描述符（S、 N、B、BOOL……）作为告诉 DynamoDB 如何解释每个属性的标记（AWS 文档），所以对 DynamoDB JSON 的朴素 CSV 转储会泄露 {"S": "..."} 包装，除非工具把它们扁平化（数据类型指南解释类型标签）。

专用客户端增加了什么

除了修复上面那些粗糙边缘，一个为 DynamoDB 构建的桌面客户端还增加了控制台从未有过的工作流便利：多标签页让你能同时打开多张表和查询，内联编辑让你在结果网格中编辑项而非往返于 JSON 编辑器，以及保存的查询让你每天重建的过滤和键条件留存下来。这些都不需要迁移你的数据——DynoTable 读取你标准的 AWS 凭证链，并与你账户中同样的表通信，包括用于离线工作的 DynamoDB Local（参见 DynamoDB Local 指南）。

控制台何时够用（何时不够）

控制台对于偶尔的小任务确实够用：扫一眼几个项、一次性的 GetItem、创建一张表，或检查一个设置。如果你每周打开一次 DynamoDB 且从不翻过第一屏，你不需要别的东西。

一旦你的工作变得重复或分析型，它就开始让人难受——翻阅数千个项、过滤一张大表而不烧读容量、导出一份完整结果集，或回答一个"有多少 / 总数是多少"的问题。那正是专用客户端，尤其是 SQL Workbench，体现其价值之处。

下载 DynoTable（macOS、Windows 或 Linux），把它指向你在控制台里用的同一个配置文件和区域，并运行一个你以前无法表达的 JOIN 或 GROUP BY。当前套餐见定价。

常见问题

有没有比 AWS DynamoDB 控制台更好的替代方案？

有。DynoTable 是一款桌面 DynamoDB 客户端，它修复了控制台的弱点—— 手动分页、扫描后过滤和单页 CSV 导出——并增加了一个 SQL Workbench，能运行控制台 PartiQL 编辑器无法表达的 JOIN、GROUP BY 和聚合。

为什么 DynamoDB 控制台不能运行 JOIN 或 GROUP BY？

控制台用 PartiQL 查询，其 SELECT 语法是单表加上一个可选的 WHERE 和 ORDER BY，且它支持的唯一聚合函数是 SIZE （AWS 文档）。 DynoTable 的 SQL Workbench 在客户端规划那些查询，把它们向下编译为 DynamoDB 真正的 Query/Scan 操作。

我需要迁移数据才能用控制台替代方案吗？

不需要。DynoTable 读取你标准的 AWS 凭证链，并指向同样的区域和表——你的数据留在 DynamoDB，所以没有什么要迁移。