AWS DynamoDB+Lambda+API Gateway栈查询10条数据耗时900ms如何优化？

小数据量查询耗时过高的常见原因 #

• Lambda冷启动占比最高：开发阶段函数调用频率低，触发冷启动时Node.js运行时初始化、依赖加载、客户端创建都会消耗时间，800ms左右的耗时基本符合Node.js Lambda冷启动的典型耗时区间。
• GSI回表开销：如果创建companyId-index时投影策略设置为KEYS_ONLY，DynamoDB查询完GSI后需要回原表拉取ProjectionExpression中指定的非主键字段，额外增加一次IO开销。
• FilterExpression后置过滤：Filter是在Query拿到结果后才执行的过滤逻辑，若匹配companyId的记录中存在大量isDeleted=true的条目，DynamoDB需要扫描更多数据才能凑够10条符合过滤条件的结果，虽然总数据量不大，但也会带来少量额外耗时。
• 客户端重复初始化：如果DynamoDB客户端是在Lambda处理函数内部创建的，每次函数触发都会重新执行初始化逻辑，增加不必要的耗时。
• 跨区域调用：如果Lambda、DynamoDB、API Gateway部署在不同AWS区域，网络延迟会直接拉高整体耗时。

具体优化方案 #

1. 先定位耗时大头
   给Lambda开启X-Ray链路追踪，可直接拆分出冷启动、DynamoDB调用、API网关各环节的耗时，优先优化占比最高的部分。
2. Lambda侧优化
   • 将DynamoDB客户端初始化移到处理函数外部，全局复用连接，避免每次调用重复创建客户端
   • 适当提升Lambda内存配置（建议调到512MB~1024MB），Lambda内存与CPU性能绑定，更高的CPU会加快Node.js代码执行速度，成本提升极低但收益明显
   • 开发阶段可配置预留并发（Provisioned Concurrency），彻底消除冷启动耗时
   • 精简Lambda部署包，移除无用依赖，降低冷启动时的包加载时间
3. DynamoDB侧优化
   • 调整GSI结构：将isDeleted作为GSI的排序键，查询时直接把isDeleted = :isDeleted放到KeyConditionExpression中，去掉FilterExpression，避免后置过滤的额外开销
   • 调整GSI投影策略：将需要返回的fullName、mobileNumber等字段全部纳入GSI投影，或者直接设置为ALL（小数据量场景无额外成本），完全避免回表查询
   • 优先使用AWS SDK v3的DynamoDB客户端，比v2更轻量，执行速度更快
4. 基础设施配置校验
   确认Lambda、DynamoDB、API Gateway都部署在同一个AWS区域，避免跨区域网络开销。

优化完成后排除首次冷启动的调用，正常场景下接口耗时可以降到100ms以内。

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