连接池溢出主因是python层连接生命周期失控，源于未归还连接、配置错配及异步上下文失效；需修复异常路径释放逻辑、禁用max_overflow盲目扩容、启用pool_recycle和pool_pre_ping，并加强连接池指标监控。
直接说结论：连接池溢出不是“加大小就行”，而是连接没及时归还、配置与实际负载错配、异步上下文管理失效这三类问题叠加导致的。90% 的 QueuePool limit of size 20 overflow 10 reached 报错，根源不在数据库，而在 Python 层的连接生命周期失控。
async with get_db() 为什么有时不释放连接？
很多人以为用了上下文管理器就万事大吉，但 async 函数里一旦出现未捕获异常或提前 return，__aexit__ 可能根本不会触发。
- 典型场景：在
await db.commit()后抛出网络异常，后续的连接归还逻辑被跳过 - 更隐蔽的情况：协程被 cancel（比如超时中断），但连接对象未被显式 close 或 release
- SQLAlchemy 1.4+ 的
AsyncSession默认不自动 rollback，异常后连接可能卡在事务中，无法复用
验证方式：在 get_db() 返回前加日志，观察是否每次调用都对应一次归还；或用 pool.checked_out() 实时打印已分配连接数。
max_overflow 不是“保命阀”，而是风险放大器
max_overflow 允许临时突破 pool_size，但它不解决连接泄漏，只掩盖症状——泄漏持续发生时，溢出连接会越积越多，最终触发 too many connections。
- MySQL 默认最大连接数通常为 151，若
pool_size=10+max_overflow=20，单个服务实例最多占 30 连接；但 5 个实例就逼近上限 - PostgreSQL 对每个连接消耗约 10MB 内存，溢出连接长期堆积会导致 DB 内存吃紧、查询变慢
- 真正该调的是
pool_recycle=3600（避免 MySQL 8 小时断连）和pool_pre_ping=True（主动剔除失效连接）
异步任务中连接持有时间过长怎么办？
像转录这类长耗时任务（>30s），如果整个处理流程都持有一个 AsyncSession，连接会被锁死，其他请求只能排队或溢出。
- 必须拆分：任务入库用一个短连接（
get_db()），执行时再按需获取新连接（不要复用入库时的 session） - 避免在循环里反复
await get_db()—— 每次调用都可能新建连接；应复用 pool 实例，用pool.acquire()显式控制 - 对
await check_and_process_task()这类轮询逻辑，每次迭代后必须确保连接已归还，不能依赖“下次迭代再关”
示例修正点：await start_processing_task(task_id) 应返回 task 状态而非直接操作 DB；DB 操作收口到单一入口函数，统一管控生命周期。
监控连接池状态比调参更重要
没有监控的调参等于蒙眼开车。光看错误日志，你永远不知道是突发流量、连接泄漏，还是某段代码悄悄 hold 住了连接。
- 暴露指标：用
engine.pool.checked_in()、engine.pool.checked_out()、engine.pool.overflow()推送 Prometheus - 关键阈值告警：当
checked_out() > pool_size * 0.8持续 1 分钟，就要查 top 耗时 SQL 和协程栈 - 别信“平均连接数”，要看
max_overflow是否频繁触达——那是泄漏正在发生的信号
最常被忽略的一点：连接池统计本身不包含被 cancel 协程持有的连接，这些连接既不算 checked_out，也不算 idle，它们静默地卡在中间态，直到 DB 主动 kill。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
