根本原因是SQLAlchemy scoped_session在Flask中不自动归还连接，必须通过@app.teardown_appcontext显式调用db.session.close()；teardown_request无法覆盖CLI、异步视图和后台任务，且异常时可能不执行，而debug=True更使teardown_appcontext不可靠。
根本原因不是连接池太小，而是连接没被归还——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，池子直到某次查询失败才踢掉它——此前所有等待该连接的协程全阻塞。
- 必须设
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 或拒绝新连接。
立即学习“Python免费学习笔记（深入）”；
- 先确认是否真缺连接：查
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 清理路径，间接加剧连接滞留。不是可选项，是必关项。
