用途
该技能聚焦在 SST 框架中使用 DynamoDB 的单表设计模式，即用一张表来建模所有实体及其复杂关系，这是 AWS 推荐的做法，适合无服务器架构。
核心理念
- 一张表承载全部实体
- 使用通用的 pk/sk 键，保持灵活
- 围绕访问模式来设计数据模型
- 在需要时进行反规范化，避免连接操作
- 策略性地使用 GSI 支持其他访问路径
优势与取舍
优势包括：所有查询性能一致、成本更低、跨实体类型可进行原子事务、基础设施管理更简单、更适合无服务器架构。取舍包括：初期设计更复杂、需要预先理解访问模式、不如关系型数据库直观。
关键概念
- 通用键名：使用 pk 和 sk 而非实体专属键名。
- 复合键：从多个属性构建键，例如
USER#userId与POST#postId。 - 项目集合：将同一分区键下的相关项目分组，可在一次查询中取出。
访问模式
文档给出了多种模式：获取单个项目（GetItem）、查询项目集合（Query + begins_with）、带排序的查询（利用 ISO 时间戳作为 sk，ScanIndexForward 控制升降序）、以及全局二级索引（GSI）查询跨用户的状态数据。
常见建模范例
包括用户与帖子及评论（含反规范化评论者信息）、多对多（用户与群组）、层级数据（文件夹与文件）、时间序列数据（按时间范围用 BETWEEN 查询指标）。
在 SST 中的实现
给出 sst.config.ts 中创建 Dynamo 表的基础配置，声明 pk/sk 与 gsi1/gsi2 键及主索引与全局索引，并启用流。还提供类型安全的键构建器（src/lib/db.ts）以及创建、读取、更新用户和查询用户帖子的 CRUD 代码示例。
最佳实践
- 先设计访问模式，再设计实体
- 使用稀疏索引，仅带 GSI 键的项目进入索引
- 策略性反规范化，避免二次查询
- 对相关项目使用事务写入
- 处理热点分区，通过加后缀分散写入
常见坑点
- 查询必须提供排序键，不能只按 pk 查询
- GSI 是最终一致性，写入后查询可能看不到最新数据
- 单项目大小上限 400KB，大内容应存 S3
- GSI 投影方式影响成本，ALL 会复制全部属性
测试与迁移
测试可使用本地 DynamoDB 端点，文中给出了用户操作的测试示例。迁移方面给出从多表迁移的策略步骤：识别访问模式、设计新键结构、编写迁移脚本、并行双写、验证完整性后再切换。