DynamoDB批量更新异常：7k条仅更新2k条，求全量更新及无停机方案

问题解答 #

1. 为什么只更新了2000条记录？ #

DynamoDB的scan() API默认有分页限制：单次调用最多返回1MB数据量或1000条项目（以先触发的阈值为准）。你的7000条记录远超这个限制，原脚本仅处理了第一次scan返回的分页数据，未遍历剩余分页结果，因此只更新了约2000条。

2. 如何确保全量更新？ #

必须处理scan的分页逻辑，通过响应中的LastEvaluatedKey字段循环调用scan，直到该字段不存在（表示所有数据已遍历）。同时推荐用batch_writer()批量执行更新，减少API调用次数、提升效率。修改后的代码如下：

import boto3

dynamodb = boto3.resource('dynamodb')
table_name = 'test-table'
table = dynamodb.Table(table_name)

last_evaluated_key = None
while True:
    # 构造scan参数，带上上次分页的起始键（如果存在）
    scan_params = {'ExclusiveStartKey': last_evaluated_key} if last_evaluated_key else {}
    response = table.scan(**scan_params)
    
    # 使用batch_writer批量更新，自动按25条/批拆分
    with table.batch_writer() as batch:
        for item in response['Items']:
            trimmed_timestamp = item['uploadedTimeStamp'][:10]
            batch.update_item(
                Key={'consumerId': item['consumerId']},
                UpdateExpression='SET trimmed_timestamp = :val',
                ExpressionAttributeValues={':val': trimmed_timestamp}
            )
    
    # 更新分页起始键，直到没有更多数据
    last_evaluated_key = response.get('LastEvaluatedKey')
    if not last_evaluated_key:
        break

3. 是否应采用batch_execute_statement方法？ #

batch_execute_statement是基于PartiQL的批量执行接口，每次最多支持25条语句，确实能减少API调用，但和batch_writer()相比：

• batch_writer()是DynamoDB资源客户端的封装，自动处理批量写入的重试、分片逻辑，适合简单批量更新场景。
• batch_execute_statement支持SQL风格语句，但需手动构造PartiQL语句，错误处理更复杂（要单独处理单条语句失败的情况）。

对你的场景来说，batch_writer()已经足够高效，无需刻意切换到batch_execute_statement。

4. 生产环境无停机更新最优方案 #

生产环境需优先保障业务不受影响，推荐两种方案：

方案一：批量分页更新（适合存量数据规模小的场景）

使用上述带batch_writer()的分页脚本，同时注意：

• 控制更新速率：比如每次批量处理后添加1秒左右的延迟，或调整batch_writer的flush_amount参数，避免打满表的写入吞吐量。
• 选择业务低峰期执行：减少对线上读写请求的资源抢占。

方案二：增量+存量分离更新（适合长期维护）

1. 增量实时处理：配置DynamoDB Streams + Lambda，对新写入/更新的记录实时计算并添加trimmed_timestamp属性，确保新数据无需后续补更。
2. 存量离线处理：在业务低峰期用分页批量脚本处理存量数据，或通过AWS Glue等ETL工具批量更新，降低对业务的影响。

如果trimmed_timestamp仅用于查询展示，还可以考虑读取时动态计算（在应用层截取uploadedTimeStamp前10位），完全避免写入更新——但如果该属性需要被索引或用于聚合查询，则必须写入表中。

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