数据库连接池耗尽的典型表现是Flask应用返回TimeoutError或请求卡在engine.connect()、session.execute()上，响应时间飙升——根本原因是连接未及时归还。
数据库连接池耗尽的典型表现是什么
Flask 应用突然返回 TimeoutError: QueuePool limit of size X overflow X reached，或大量请求卡在 engine.connect()、session.execute() 上，响应时间飙升甚至超时——这基本是连接池已满且无空闲连接可分配。根本原因不是并发高，而是连接没及时归还。
SQLAlchemy 的 pool_size 和 max_overflow 怎么设才合理
这两个参数必须一起理解：pool_size 是常驻连接数，max_overflow 是超出后可临时创建的额外连接上限（用完即销毁）。设得过大，数据库端连接数爆炸；设得太小，高并发下排队严重。
- 默认值（
pool_size=5,max_overflow=10）只适合本地开发或极低流量场景 - 生产环境建议：先估算峰值并发请求数，再按「每个请求平均持有连接时间」反推。例如 100 QPS、平均 DB 操作耗时 200ms → 理论需约 20 个活跃连接 → 可设
pool_size=15,max_overflow=5 - 务必配合数据库最大连接数限制（如 PostgreSQL 的
max_connections），总预留连接数（应用实例数 × pool_size + max_overflow）不能越界
Flask 中 session/transaction 没正确关闭导致连接泄漏
最常见坑：在视图函数里手动创建 session = Session() 却忘了 session.close()，或用了 try/except 但没在 finally 里关；更隐蔽的是使用了 scoped_session 却没配好 Flask 的 teardown_appcontext 钩子。
- 推荐方式：用 Flask-SQLAlchemy，它自动绑定
db.session.remove()到teardown_appcontext，无需手动干预 - 若手写 SQLAlchemy，必须确保每个请求结束前调用
db.session.remove()（不是close()），否则 scoped_session 会复用旧 session，连接不释放 - 避免在循环或长任务中反复
session.add()后不session.commit()或session.rollback()—— 未提交的 session 会一直占用连接
异步任务、后台线程或信号处理中误用主线程 session
用 Celery、APScheduler 或 threading.Thread 执行数据库操作时，若直接复用 Flask 主线程的 db.session，会引发连接被多个线程共享、状态混乱，最终连接卡死或报 InvalidRequestError: This Session's transaction has been rolled back。
立即学习“Python免费学习笔记（深入）”；
- 所有后台任务必须创建独立 session：用
Session = sessionmaker(bind=engine)新建，操作完显式session.close() - Celery 任务中不要依赖 Flask 的上下文，也不要用
current_app获取 db 实例；改用原始 engine 构建 session - 检查信号（如
@user_logged_in.connect）是否在非请求上下文中触发了 DB 操作 —— 这类回调容易漏掉 session 生命周期管理
连接池问题往往不是参数调得不够大，而是连接在某个环节被“借走不还”。重点盯住 session 创建位置、关闭时机、跨上下文使用这三个点，比盲目调高 pool_size 有效得多。
