queuepool溢出本质是连接未归还、持有过久或并发超载，非简单调大池参数可解；size 20 overflow 10 表示30连接全占满，新请求30秒超时失败，高并发下大量报错致服务“假宕机”。
直接结论：连接池溢出不是“加大小”能解决的问题，本质是连接没归还、用得太久、或并发远超数据库承载能力。
为什么QueuePool limit of size 20 overflow 10 reached会触发宕机？
这个错误来自 SQLAlchemy 的 QueuePool，意思是：池里最多只允许 20 个常驻连接 + 10 个临时溢出连接，但所有 30 个都被占着不放，新请求等了 30 秒（timeout=30.00）还是拿不到，直接抛异常中断请求——高并发下大量请求失败，服务就“看起来宕机”了。
常见诱因包括：
- 异步任务中用了
get_db()但没走async with，或者await db.commit()后忘了await db.close() - 在数据库连接持有期间做了耗时操作（比如调外部 API、大文件处理），导致连接卡死几十秒
- FastAPI 依赖注入返回的是未包装的
Session实例，异常路径下跳过了关闭逻辑 -
max_overflow设得过大（如 50），反而让数据库瞬间收到上百连接，被主动拒绝
pool_pre_ping=True 和 pool_recycle 必须开，但不能替代正确释放
pool_pre_ping=True 会在每次从池里取出连接前发一条 SELECT 1 检查是否还活着，避免拿到已被数据库断开的“僵尸连接”；pool_recycle=3600 强制每小时重建一次连接，防止长连接被防火墙或数据库 idle timeout 清掉。
但这俩只是兜底手段，解决不了根本问题：
- 如果连接一直被某个协程占着不放，
pre_ping根本轮不到它（因为没归还，池里没空位可取） -
recycle只影响连接对象生命周期，不强制归还——占用中的连接不会被回收 - 它们会轻微增加每次获取连接的延迟（约 0.5–1ms），对高频小查询有感知
检查并修复连接泄漏的三个关键位置
从你贴出的代码看，风险点非常典型：
-
async def create_task(...)中用了async with get_db() as db:—— 这段安全，但仅限于该函数内；若后续任务（如process_transcribe_request）又单独调get_db()，就可能新开连接而不共享 -
check_and_process_task里有while True循环 +await asyncio.sleep(30)，但循环内没保证每次迭代都用同一个db实例，也未限制重试次数，容易累积多个未关闭连接 -
_process_transcribe_task如果内部再调用其他 DB 操作且没复用传入的db，就会重复申请连接
实操建议：
- 所有数据库操作必须复用同一个
db实例，不要在子函数里再调get_db() - 把
while True改成带最大重试次数的循环（如for _ in range(5)），避免无限等待耗尽连接 - 在
process_transcribe_request开头加日志：Logger.debug(f"DB connection id: {id(db)}")，确认是否真复用了
连接池大小不是拍脑袋定的，要匹配数据库和业务特征
你的报错里 size 20 overflow 10 是典型“设大了又没管住”的配置。实际应按以下逻辑调整：
- 先查数据库最大连接数：
SHOW VARIABLES LIKE 'max_connections';（MySQL）或SHOW max_connections;（PostgreSQL）—— 假设是 200，那所有应用实例的连接池总和不能长期接近这个值 - 单个 FastAPI 实例推荐
pool_size=5–10+max_overflow=5，足够应付短平快请求；高 IO 任务（如转录）应走消息队列+独立 worker，别挤在 Web 进程里抢连接 - 用
psycopg2或aiomysql替代 SQLAlchemy ORM 做纯查询时，连接更轻量，可适当提高maxsize，但依然要配timeout防死等
最容易被忽略的一点：连接池参数只控制“客户端行为”，真正决定系统是否扛得住的，是每个请求**持有连接的时间长度**。哪怕池子设成 100，只要一个请求占连接 60 秒，4 个并发就能打满——所以优先优化慢查询、拆分长事务、把非 DB 操作移出 async with 块。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
