DynamoDB Scan查询151条数据耗时7+秒，添加GSI能否提速？

1. 当前Scan操作耗时7秒确实不符合预期 #

151条记录、666KB的表规模，正常Scan操作（哪怕带过滤）的耗时应该在几百毫秒到1秒以内，7秒属于异常情况。可能的原因包括：

• Lambda内存配置过低：内存不足会导致CPU性能受限，处理速度变慢，建议至少配置256MB以上内存。
• Lambda冷启动：首次调用或长时间闲置后的调用会触发冷启动，耗时会显著增加，可以多次测试暖启动后的耗时对比。
• SDK版本老旧：使用AWS SDK v3比v2性能更优，旧版本可能存在性能瓶颈。
• 全表扫描后过滤的低效性：虽然数据量小，但Scan是先全表读取再过滤，本身效率低于Query，但也不至于慢到7秒，优先排查前几点。

2. 添加GSI改用Query操作，完全可以将耗时降至1-3秒以内（甚至更快） #

Query操作直接基于索引定位数据，不需要全表扫描，效率远高于Scan。针对你的查询条件（archived=false + status=指定值），GSI的设计建议如下：

• 创建GSI：将status设为分区键，投影所有属性（或至少包含archived和业务需要的属性）。
• 改写查询代码：用Query替代Scan，示例代码如下：

const customPois = await klass.query({
  KeyConditionExpression: 'status = :status',
  FilterExpression: 'archived = :archived',
  ExpressionAttributeValues: {
    ':status': status,
    ':archived': false
  },
  IndexName: 'status-gsi' // 你的GSI名称
}).exec();

这样Query会直接扫描status对应的GSI分区，再过滤archived=false的条目，数据读取量大幅减少，耗时通常能控制在几百毫秒内，远低于1-3秒的预期。

额外优化建议 #

如果archived=false是绝大多数数据的状态，可以考虑在写入数据时，仅将archived=false的条目写入GSI（通过DynamoDB的条件写入或触发器实现），进一步缩小GSI的规模，提升查询速度。

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