dynamodb 性能缓慢通常源于容量配置不当——默认的 1~10 rcus/wcus 预置模式严重限制吞吐量，即使启用自动扩缩容也存在分钟级延迟；切换至按需模式可立即将 7k 条写入从 30 分钟降至秒级，并使 gsi 查询响应进入毫秒级。
dynamodb 性能缓慢通常源于容量配置不当——默认的 1~10 rcus/wcus 预置模式严重限制吞吐量，即使启用自动扩缩容也存在分钟级延迟；切换至按需模式可立即将 7k 条写入从 30 分钟降至秒级，并使 gsi 查询响应进入毫秒级。
您当前遇到的性能瓶颈（7k 条记录写入耗时约 30 分钟、单次 GSI 查询达 1 分钟、甚至 10 条批量写入需 300ms）并非代码逻辑或表结构设计的根本性错误，而是一个典型的 容量模型误配问题。
? 根本原因：预置容量严重不足 + 自动扩缩容响应滞后
DynamoDB 默认创建的表使用 预置读/写容量单位（RCU/WCU），初始值仅为 1 RCU / 1 WCU（即每秒最多 1 次最终一致性读 或 1 次 1KB 写入）。虽然您启用了自动扩缩容（Auto Scaling），但其工作机制是：
- 基于 CloudWatch 指标（如 ConsumedReadCapacityUnits）每 1–5 分钟采样一次；
- 每次扩容仅增加固定百分比（如 20%），需多轮迭代才能从 1 WCU 增至 10 WCU；
- 完全无法应对突发流量（如 Kafka 消费端一次性推送 10 条记录），导致大量 ProvisionedThroughputExceededException，触发重试与退避，显著拖慢整体耗时。
✅ 举例：写入 10 条平均 0.8KB 的记录，理论仅需 ≈10 WCUs；但若表长期处于 1 WCU 状态，DynamoDB 将串行化处理——10 次写入需至少 10 秒（不计网络与客户端开销），这与您观察到的 ~300ms/批明显不符，说明实际已触发多次限流重试。
? 推荐解决方案：立即切换为 按需容量模式（On-Demand Mode）
对于您的场景（Kafka 消费驱动、数据量中等、流量波动大、无长期稳定高负载），按需模式是最优且最简方案：
- 完全免去容量预估、扩缩容配置与监控告警；
- 吞吐量自动弹性伸缩，峰值支持高达 40,000 WCUs/RCUs（无需预热）；
- 写入 7k 记录可在数秒内完成（实测典型耗时
- GSI 查询延迟回归正常水平（通常
- 成本按实际请求量计费，对间歇性负载更经济（7k 写入 + 若干查询 ≈ $0.02–$0.05）。
✅ 切换操作（AWS CLI 示例）：
aws dynamodb update-table \ --table-name YourTableName \ --billing-mode PAY_PER_REQUEST
⚠️ 注意：切换过程在线、零停机，但需确保 IAM 策略允许 dynamodb:UpdateTable 权限。
?️ 补充优化建议（在按需模式基础上进一步提效）
-
批量写入保持合理分片
您当前使用 WriteBatch 是正确的，但注意：- 单次 batchWriteItem 最多支持 100 条（DynamoDB 服务限制）；
- 建议将 List
按每批 ≤100 条分组提交，避免因部分项失败导致整批重试。
-
GSI 查询避免全扫描，确保键条件精准
您的查询代码：QueryConditional q = QueryConditional.keyEqualTo( Key.builder().partitionValue(itemCategory).sortValue(itemDate).build() );✅ 正确利用了 GSI 的 PK=category & SK=date 复合键，属高效点查（O(1) 级别）。
❌ 请勿改为 beginsWith 或无 sortValue 的纯分区键查询——这将退化为 GSI 扫描，大幅降低性能。 客户端连接复用与异步增强（可选）
确保 DynamoDbEnhancedClient 为单例（Spring Boot 中应通过 @Bean 注入），避免重复初始化 HTTP 连接池；如需极致吞吐，可考虑 batchWriteItem 异步变体（batchWriteItemAsync）并行提交多个批次。
✅ 总结
| 问题现象 | 根本原因 | 解决动作 | 预期效果 |
|---|---|---|---|
| 7k 写入耗时 30 分钟 | 预置容量长期卡在 1–2 WCU | 控制台/CLI 切换为 PAY_PER_REQUEST | 写入降至 3–8 秒 |
| 10 条写入需 300ms | 自动扩缩容未及时响应突发 | 同上 | 单批写入稳定 |
| GSI 查询 1 分钟 | 限流导致查询排队/重试 | 同上 + 确认查询条件精确匹配 PK+SK | 查询稳定 |
? 最后提醒：按需模式不是“银弹”，但在您描述的 Kafka 消费 + 中小规模 + 流量不可预测场景下，它是 DynamoDB 入门与快速落地的最佳实践起点。待业务稳定后，若出现持续高吞吐（如 >1000 WCU 持续小时级），再评估回归预置模式+精细化 Auto Scaling 策略。
