SQLAlchemy函数执行失败时连接自动关闭问题与处理方案

• 这类未捕获异常触发请求崩溃时，connection.close()不会被执行，对应数据库连接会脱离SQLAlchemy连接池的管理，成为应用侧持有的僵尸空闲连接，不会被应用主动释放。
• 不存在永久存活的连接。所有数据库服务端都自带空闲连接清理规则：比如MySQL默认wait_timeout为8小时、PostgreSQL可通过idle_in_transaction_session_timeout配置空闲回收阈值，超过阈值的空闲连接会被数据库主动断开。但在数据库触发回收前，这类僵尸连接会持续占用数据库连接配额，高并发场景下短时间内就可能耗尽数据库最大连接数，直接导致服务不可用。

完全不需要手动写try/except块做异常分支的连接关闭，SQLAlchemy原生提供了更可靠的零侵入处理方案：

1. 使用连接上下文管理器，自动处理全场景的连接释放
   上下文管理器会在代码块退出时（不管是正常执行结束、抛出异常、还是return提前返回）自动执行连接回收逻辑，不会遗漏释放分支，示例代码如下：

   @app.route("/function")
   def function():
       engine = sqlalchemy.getEngine()
       # 退出with代码块时连接自动归还连接池，无需手动调用close
       with engine.connect() as connection:
           result = utils.doThings(connection)
   

   注意：SQLAlchemy默认使用连接池，这里的"释放连接"是把连接归还给连接池复用，不是直接断开物理TCP连接，不会带来额外的连接建立开销。

2. 给连接池配置兜底回收规则，做双重保险
   初始化Engine的时候可以加几个连接池配置，从机制上避免连接泄漏、死连接问题：
   • pool_recycle：设置连接最大存活时长，一般设为比数据库端空闲回收时长短1/3左右，比如对应MySQL默认8小时超时可以设为1800（30分钟），避免连接被数据库主动断开后应用还在复用死连接。
   • pool_pre_ping=True：每次从连接池取出连接前先发一个极轻量的探活请求，如果连接已经失效直接丢弃新建，彻底避免使用死连接报错的问题。
   • pool_timeout：设置从连接池获取连接的最大等待时长，避免连接耗尽时请求无限阻塞。

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