首先直接给结论：很大概率是读写容量限制导致的，但也需要结合具体指标和代码逻辑排查确认。下面一步步拆解问题：

一、核心疑问：是否因超出读写容量限制？ #

DynamoDB的预置读写容量（RCU/WCU）是硬限制——当你的请求消耗的容量持续超过预置值时，会触发ProvisionedThroughputExceededException限流，导致请求失败或延迟。结合你的场景：

• 批量更新每条记录时，不仅会消耗主表的写容量（WCU），如果更新操作会同步触发索引更新（比如更新的字段属于索引键，或主表更新会同步刷新索引数据），还会额外消耗索引的WCU（比如全局二级索引GSI，主表每写1条，GSI也要同步写1条，相当于1次更新消耗2倍WCU）。
• 你配置了80单位WCU，假设每条更新实际消耗2WCU，那每秒最多只能处理40条记录。94000条理论上需要约40分钟才能完成，如果任务执行时长不足、或未处理限流重试，就会只完成部分更新。

当然，也存在其他可能性（比如代码逻辑错误、查询索引时未获取全量数据），但容量限流是最常见的原因。

二、排查步骤 #

1. 查看CloudWatch关键指标 #

登录AWS控制台，找到你的DynamoDB表对应的CloudWatch指标，重点看：

• WriteThrottleEvents：如果这个指标有非零值，说明明确触发了写限流，坐实容量不足的问题。
• ConsumedWriteCapacityUnits vs ProvisionedWriteCapacityUnits：如果Consumed持续接近或超过Provisioned，说明容量被打满，请求被限流。
• 还要检查索引的对应指标（比如GSI的WriteThrottleEvents），因为索引的容量瓶颈也会拖慢主表更新。

2. 检查批量更新代码逻辑 #

• 有没有处理ProvisionedThroughputExceededException？如果代码遇到这个错误就直接终止，没有重试，那会导致大量请求失败，最终只完成部分更新。
• 是不是用了单条UpdateItem而不是BatchWriteItem？单条请求的效率低，更容易触发限流。
• 有没有确认从索引查询到的是全量94000条记录？如果查询索引时因为分页或过滤条件错误，只拿到了一半数据，那更新自然只完成一半。

3. 确认索引的容量配置 #

如果是全局二级索引（GSI），它可以单独配置读写容量——如果GSI的WCU远低于主表，那主表更新时GSI会先被限流，导致主表更新也卡住。

三、解决方案 #

1. 临时扩容读写容量（最快解决） #

如果是预置容量模式：

• 计算需要的WCU：假设每条更新消耗2WCU，要在30分钟内完成94000条，需要(94000 / (30*60)) * 2 ≈ 104 WCU，可以临时把主表和对应索引的WCU调高到150左右（留冗余），任务完成后再调回80，避免不必要的成本。
• 或者直接切换到按需容量模式：DynamoDB会自动根据请求量扩容，不会触发限流（成本会比预置高，但适合短期批量任务）。

2. 优化批量更新代码 #

• 使用BatchWriteItem API：每次最多可以批量处理25条记录，减少请求次数，提高效率，同时降低限流概率。
• 实现指数退避重试：遇到ProvisionedThroughputExceededException时，按照1s、2s、4s...的间隔重试（AWS SDK大多内置了这个机制，比如Java的RetryPolicy，Python的botocore重试配置），确保限流时不会丢失请求。
• 控制并发数：如果是多线程/异步处理，不要一次性发起大量请求，把并发数控制在容量允许的范围内（比如80WCU，每条消耗2WCU，并发数控制在40以内）。

3. 分批次低峰期处理 #

如果不想临时扩容，可以把94000条分成多个批次（比如每次处理10000条），在业务低峰期执行，每次间隔一段时间，避免持续打满容量。

4. 优化索引使用 #

如果更新是基于索引查询记录，建议先通过索引查询出所有记录的主键（Partition Key + Sort Key），然后直接根据主键批量更新主表——这样可以减少索引的读写消耗，因为查询索引只消耗RCU，而更新时只需要操作主表（如果索引字段不需要更新的话）。

内容的提问来源于stack exchange，提问作者ROHIT