为什么Python Flask应用在大规模并发下会出现连接池溢出？-Python教程-PHP中文网

根本原因是sqlalchemy scoped_session在flask中不自动归还连接，必须通过@app.teardown_appcontext显式调用db.session.close()；teardown_request无法覆盖cli、异步视图和后台任务，且异常时可能不执行，而debug=true更使teardown_appcontext不可靠。

为什么python flask应用在大规模并发下会出现连接池溢出？

根本原因不是连接池太小，而是连接没被归还——SQLAlchemy 的 scoped_session 在 Flask 中不会自动清理，必须手动 close。

teardown_appcontext 必须用，不能用 teardown_request

很多项目把 db.session.close() 放在 @app.teardown_request 里，这会导致 CLI 命令、异步视图（async def）、后台任务完全跳过清理逻辑，连接就此卡死在池中。

@app.teardown_appcontext 覆盖所有上下文：HTTP 请求、flask shell、flask run、Celery 任务（只要走 Flask app context）
teardown_request 只在请求响应周期触发，且异常未被捕获时可能根本不执行
开发模式下 app.debug=True 会让 teardown_appcontext 行为不可靠，线上务必关掉 debug

pool_pre_ping 不开，失效连接会堵死整个池

PostgreSQL/MySQL 连接可能因防火墙超时、DB 重启或网络闪断变成“假存活”状态：连接对象还在，但一发 SQL 就卡住或报 Lost connection。默认 pool_pre_ping=False，池子直到某次查询失败才踢掉它——此前所有等待该连接的协程全阻塞。

python-parallelization

将顺序 Python 代码转换为并行/并发实现，用于在需要并行化 Python 代码、提升性能时使用。

下载

必须设 SQLALCHEMY_ENGINE_OPTIONS = {"pool_pre_ping": True}
搭配 pool_recycle=3600（1 小时），防止 DB 主动断开后连接滞留
注意：pool_pre_ping 每次取连接多 1–2ms RT，但远好于整池挂死

max_overflow 不是越大越好，调高反而压垮数据库

看到 QueuePool limit of size 5 overflow 10 reached 就猛加 max_overflow 是典型误操作。每个 MySQL 连接在服务端占约 10–20MB 内存，设成 100 意味着 DB 端瞬时多扛 1–2GB 内存压力，极易触发 OOM 或拒绝新连接。

先确认是否真缺连接：查 SELECT * FROM pg_stat_activity;，看是否有大量 idle in transaction
优先调优 pool_size（建议 5–10） + max_overflow（建议 5–10），而非无脑拉高
配合 Gunicorn 配置：比如 --workers 4 --threads 2，总并发上限 ≈ (pool_size + max_overflow) × workers × threads，别超过 DB 实际承载能力

最常被忽略的一点：用了 flask-sqlalchemy 却没关 SQLALCHEMY_TRACK_MODIFICATIONS=False，这个开关开启后，模型变更监听器会拖慢 session 清理路径，间接加剧连接滞留。不是可选项，是必关项。