Amazon DynamoDB表删除耗时过长问题该如何解决？

该问题属于DynamoDB的常见现象，大量用户在控制台、SDK调用场景下都遇到过同类表现，核心原因和对应处理方案如下：

常见触发原因 #

• 表附加资源多：如果表开启了时间点恢复（PITR）、DynamoDB Streams、全局表同步，或者绑定了Lambda触发器、GSI索引，删除操作需要后台同步清理所有关联资源，会大幅拉长耗时
• 表规模大：表内存储数据量超过100GB、配置的RCU/WCU阈值较高，或者删除前刚完成大规模数据写入、分区拆分、容量调整操作，未完成的后台事务会阻塞删除任务执行
• 多租户调度排队：DynamoDB是多租户托管服务，当同一可用区的删除操作处于峰值时，任务会进入后台调度队列等待，偶发出现10~20分钟的长耗时属于官方公开的预期行为

对应处理方案 #

• 提前解除附加关联：删除表之前先手动关闭PITR、删除关联的Streams、解除全局表绑定、删除不需要的GSI索引，再执行删除操作，可降低70%以上的长耗时概率
• 小表优先清数据再删除：如果是容量小于10GB的测试表，可先调用BatchWriteItem接口清空表内数据，再执行删除表操作，耗时会稳定在1分钟以内
• 调整SDK等待逻辑：使用boto3调用删除接口时，不要用同步阻塞逻辑等待返回，使用官方提供的等待器配置合理的超时参数，避免业务逻辑报错，参考代码如下：

import boto3

dynamodb_client = boto3.client("dynamodb")
dynamodb_client.delete_table(TableName="your_table_name")
# 配置等待器：每30秒轮询一次，最多等待30分钟，覆盖官方公布的最长预期耗时
waiter = dynamodb_client.get_waiter("table_not_exists")
waiter.wait(
    TableName="your_table_name",
    WaiterConfig={"Delay": 30, "MaxAttempts": 60}
)

• 极端情况提工单打点：如果删除操作耗时超过30分钟仍未完成，可直接在AWS支持中心提交服务工单，由后台人工处理阻塞的删除任务

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