Lambda函数在handler外执行数据库查询的影响及最佳实践问询

我现有AWS Lambda函数伪代码如下：

import pandas
import pymysql


def get_db_data(con_):
    query = "SELECT * FROM mytable"
    data = pandas.read_sql(query, con_)
    return data


def lambda_handler(event, context):
    con = pymysql.connect()
    data = get_db_data(con)
    """
    do other things with event
    """
    con.close()

考虑修改为以下形式：

import pandas
import pymysql

con = pymysql.connect()


def get_db_data(con_):
    query = "SELECT * FROM mytable"
    data = pandas.read_sql(query, con_)
    return data


data = get_db_data(con)


def lambda_handler(event, context):
    """
    do other things with event
    """
    con.close()

想了解第二种方案对运行时、成本的影响，以及是否违反推荐规范。

运行时影响 #

• 冷启动阶段：Lambda冷启动时会优先执行函数外的代码，也就是修改后的con = pymysql.connect()和data = get_db_data(con)都会在lambda_handler执行前完成，这会直接拉长冷启动耗时——原来的方案是在handler里按需执行这些操作，冷启动只会加载依赖、初始化基础环境。
• 热启动阶段：如果Lambda实例被复用（热启动），函数外的代码不会重复执行，con和data会保留之前的结果。但这里存在两个隐患：一是数据库连接可能因超时失效，复用失效连接会直接报错；二是如果数据库数据更新，热启动时复用的data还是旧数据，会导致业务逻辑出现数据不一致的问题。

成本影响 #

• 冷启动成本增加：冷启动时额外的数据库连接、数据查询操作会增加函数的总执行时长，Lambda是按执行时长和内存配置计费的，冷启动次数多的话，整体成本会有所上升。
• 热启动存在资源浪费：如果Lambda实例被复用，但后续请求不需要用到提前查询的data，那之前查询数据消耗的计算资源就白白浪费了，相当于多支付了不必要的费用。

规范与最佳实践 #

这种修改方式违反AWS Lambda的推荐规范，核心原因如下：

• 函数外代码不可控：Lambda函数外的代码执行时机、次数完全由平台调度决定，依赖外部资源（比如数据库）的操作放在这里，会导致连接失效、数据不一致等难以排查的问题。
• 资源泄漏风险：修改后的代码仅在handler里关闭连接，但如果冷启动后没有触发handler（比如实例被销毁前没收到请求），数据库连接不会被正常关闭，长期下来可能导致数据库连接池耗尽。
• 违背按需执行原则：Lambda的设计逻辑是按需处理请求，所有与请求强相关的操作都应该放在lambda_handler内，确保每次请求都能获取最新数据、建立有效连接。

内容的提问来源于stack exchange，提问作者d.b