Lambda超时后Redshift临时表未出现是否为正常行为咨询

你的这个情况其实是符合预期的，核心原因在于Redshift的事务机制和Lambda超时对数据库会话的影响，我来拆解一下：

• 事务的原子性与回滚：如果你的Lambda是在同一个数据库会话里依次执行CREATE TABLE xyz和COPY xyz FROM S3，这两个操作默认会处于同一个未提交的事务中。Redshift的事务是原子性的——只有当整个事务的所有步骤都完成并显式提交后，所有变更才会生效。当Lambda因为5分钟超时终止时，它会直接断开与Redshift的连接，这会触发Redshift自动回滚当前未提交的事务。不管COPY命令有没有在后台跑完，只要事务没提交，创建的表（包括你预期的临时表）都会被彻底回滚，自然找不到痕迹。

• 临时表的会话绑定特性：另外如果你创建的是TEMP TABLE（临时表），它本身是和创建它的数据库会话绑定的。一旦Lambda超时导致会话断开，Redshift会自动销毁这个会话关联的所有临时表，哪怕COPY完成了，你也看不到它。

给你几个优化建议，避免这种情况：

• 拆分事务：先执行CREATE TABLE并显式提交事务，再单独发起COPY操作，这样就算后续COPY超时，表至少会保留下来。
• 改用异步监控：不要让Lambda一直等待COPY完成，而是提交COPY任务后就返回，然后通过Redshift的系统表（比如STL_QUERY、STL_LOAD_ERRORS）来监控任务状态，后续再用另一个Lambda或者Step Functions来处理结果。
• 换用更适合长任务的服务：Lambda的最大15分钟时限确实不适合跑大型COPY，你可以考虑用ECS容器、Batch或者Step Functions来编排这类长时间运行的数据加载任务。

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