用 AWS CLI 做 DynamoDB GetItem

在 CLI 上，键是一个 DynamoDB JSON 字符串，每个值都用它的类型包起来（{"S": "..."}、{"N": "..."}），这意味着 aws dynamodb get-item 的难点大多在 shell 引号上，而不在 DynamoDB 上。键本身仍然必须是完整主键。

代码

aws dynamodb get-item \
  --table-name 'Music' \
  --key '{"Artist":{"S":"Arturo Sandoval"},"SongTitle":{"S":"Cubano Chant"}}' \
  --projection-expression '#proj0, #proj1, #proj2, #proj3' \
  --expression-attribute-names '{"#proj0":"Artist","#proj1":"SongTitle","#proj2":"AlbumTitle","#proj3":"Year"}'

响应会以 DynamoDB JSON 打印这个项：

{
  "Item": {
    "Artist": {"S": "Arturo Sandoval"},
    "SongTitle": {"S": "Cubano Chant"},
    "AlbumTitle": {"S": "Danzon"},
    "Year": {"N": "1994"}
  }
}

说明

没命中时什么都不打印——没有 Item，没有空对象，退出码 0。把它直接管道给 jq 会因为输入为空而失败，所以先把输出接住、判断一下字符串再去解析。
加引号才是真正的工作——在 bash 和 zsh 上给 JSON 加单引号，好让 $ 和 ! 保持字面量。Windows 的 cmd 和 PowerShell 规则不同；与其跟它们较劲，不如把键放进文件、用 --key file://key.json 传进去。
--query 不是 --projection-expression——--query 是 JMESPath，在项已经被读取并计费之后、在你自己机器上生效。--projection-expression 才是 DynamoDB 看得到的那个。两者都不会降低读取成本（为什么）。
#proj0 这些别名是必需的，不是风格问题——Year 在 AWS 的保留字列表上，在投影里直接写它会被拒绝。
问一问它花了多少——加上 --return-consumed-capacity TOTAL，响应里就会多出一个 ConsumedCapacity 块。对这个不到 4 KB 的项来说，那是 0.5 个容量单元；一旦加上 --consistent-read 就是 1.0（这里的取舍）。
CLI v2 会给你的输出分页——默认情况下，macOS 和 Linux 上所有输出都会经过 less（带 FRX 标志），Windows 上则是 more。在脚本里这几乎从来不是你想要的：传 --no-cli-pager，或者把 AWS_PAGER 设成空字符串。

用可视化的方式来做

手敲那一坨 --key 才是时间的去处。DynamoDB 表达式构建器会从一个表单里生成 DynamoDB JSON 和别名映射，然后把一条可以直接运行的 aws dynamodb 命令交给你。

DynoTable 在真实的表上做同样的事：在表格里浏览行，然后把这些行背后的查询导出成一条 CLI 命令。下载 DynoTable。

参考资料

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

用 AWS CLI 做 DynamoDB GetItem

代码

说明

用可视化的方式来做

相关指南

参考资料