使用Global Secondary Index查询5000条数据耗时800ms，是否正常？

这个耗时不完全属于理想的性能表现，但也在可能出现的合理范围内，具体得结合以下几个关键因素判断：

影响性能的核心因素 #

• 查询结果集的大小：你的代码里没有设置Limit或ProjectionExpression，如果id = :myId匹配到的条目数量多（比如几百上千条），或者单条数据属性多、体积大，数据传输和序列化会占用大量时间。DynamoDB单页查询最多返回1MB数据，即便结果超过这个限制只返回第一页，查询和传输的耗时也会随数据量增加而上升。
• GSI的配置状态：
  • 若GSI采用ALL投影类型，每次查询会返回所有属性，数据量远大于仅投影所需字段的情况，自然会拉长耗时；
  • 新创建的GSI需要一段时间完成数据同步，同步期间查询性能会明显下降，需确认GSI是否处于完全可用状态。
• Lambda执行环境：
  • 冷启动会额外增加耗时，如果是热环境下的查询，那800ms主要来自DynamoDB的查询和数据传输；
  • Lambda的内存配置直接关联CPU和网络带宽，内存越高，数据处理和传输的效率越高，耗时会相应降低。
• DynamoDB容量配置：
  • 按需模式下，突发请求可能引发短暂的性能波动；
  • 预配置模式需检查读写容量是否充足，查看CloudWatch的ReadThrottleEvents指标，若存在节流情况，会直接导致查询延迟升高。

优化建议 #

• 先确认查询匹配的条目数和返回数据体积，添加Limit限制返回数量，或用ProjectionExpression只获取需要的属性，减少数据传输量；
• 调整GSI的投影类型，改为仅投影查询所需的属性；
• 查看Lambda和DynamoDB的CloudWatch日志与指标，排查是否存在冷启动、节流等问题；
• 尝试提高Lambda的内存配置，测试性能变化。

你的查询代码 #

const queryCommandInput: QueryCommandInput = {
  TableName: 'Table',
  IndexName: 'index',
  KeyConditionExpression: 'id = :id',
  ExpressionAttributeValues: { ':id': 'myId' }
}

let foundItems: JourneysTableItem[] = []

try {
  const output = await documentClient.send(new QueryCommand(queryCommandInput))

  foundItems = output.Items as JourneysTableItem[]
      
} catch (error) {
  console.log(error)
}

return foundItems

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