如何在Python FastAPI框架下利用异步数据库驱动提升并发响应能力？

先说结论：要用 async 驱动 + async 依赖项 + 连接池，这三个东西，一个都不能少。少了任何一个，表面上你在写异步代码，实际上线程还是在那里堵着，吞吐量不升反降，折腾半天还不如老老实实用同步方案。

我见过不少团队，明明上了 asyncpg，压测结果出来却让人大跌眼镜。问题通常就出在下面这几个环节。

asyncpg / aiomysql 这些驱动，为什么不能 import 进来就直接用？

最常见的坑，是在代码里写下 import asyncpg，然后在 async def 函数里直接调用 asyncpg.connect()。这看起来没毛病，但仔细想想——每次请求都新建一个数据库连接，压测时请求量上来，数据库的连接数瞬间就被打满了，超时、拒绝连接接踵而至。

• 核心认知：异步驱动不等于自动帮你管理连接池。asyncpg.connect() 就是一次性的单次连接，用完就丢，没有复用一说。
• 必须显式地用 asyncpg.create_pool() 来创建连接池。如果你用 ORM，比如 SQLAlchemy 1.4 以上版本，也得用 create_async_engine(pool_pre_ping=True) 来创建引擎。
• 连接池的初始化，应该放在应用启动时，比如 @app.on_event("startup") 里，而不是在每次请求处理过程中去创建。否则，你等于没做连接池，甚至比不用还慢。

get_db 依赖项里 yield db 之前，到底要不要 await？

这是一个非常容易让人疑惑的点。许多代码在这个地方漏掉了 await，结果 FastAPI 得到的不是数据库连接，而是一个协程对象。它不会主动报错，而是静默地失败，或者给你抛一个 TypeError: object ... is not asynchronous，或者直接返回 500。

• 正确的做法：db = await database_pool.acquire()（如果你用 asyncpg.Pool），或者 db = await AsyncSessionLocal()（如果用 SQLAlchemy）。
• 错误的写法：db = database_pool.acquire()。少了 await，得到的是个 coroutine 对象，后面再调用 fetch_one，就会得到 RuntimeWarning: coroutine 'Pool.acquire' was never awaited 这样的警告。
• 简单说：在 yield 之前，如果你没有 await 获取连接，FastAPI 无法把这个“假连接”注入到你的路由函数参数里，最终表现就是接口报错或者直接返回空。

明明用了 async 驱动，压测 QPS 却和同步版本差不了多少？

问题出在哪儿？大概率是你在异步代码里混用了同步库，或者无意中阻塞了事件循环。

别忘了，FastAPI 的并发收益，只对真正异步的 I/O 路径才生效。一旦某个请求里出现了下面的操作，整个 Web Worker 都得停下来等它走完。

• 检查一下你的 async def 里有没有偷偷用 time.sleep()、requests.get()、json.load() 这些同步操作？它们会直接冻结事件循环。
• 外部 HTTP 请求，必须换成 httpx.AsyncClient，不能用 requests。这是原则问题。
• 文件读写，要用 asyncio.to_thread(open, ...) 或者 aiofiles，别用内置的 open()。
• ORM 查询，必须用 .execute().fetch_all()（比如 SQLModel / Tortoise）或者 session.execute(...).scalars().all()（SQLAlchemy async 模式），不能用那个默认同步的 .all()。

连接池 max_size 设多大才合适？

这没有一个标准答案，但有个粗略的预估方法：用「预期的并发请求数 × 平均每个请求需要查几张表」，然后再加 20% 当作缓冲。超过 20 到 30 之后，收益通常就开始递减了，管理开销反而变大。

• 举个例子：如果你的应用峰值是 1000 QPS，平均每个请求查 2 张表，那可以试试 min_size=10, max_size=30。
• 一定要记得检查 PostgreSQL 服务端的 max_connections 设置。它必须 >= 你应用连接池的 max_size × 实例数，否则新连接会被拒绝。
• 务必开启 pool_pre_ping=True（SQLAlchemy）或者设置 min_size > 0（asyncpg），这样能避免拿到已经失效的连接。
• 闲置连接超时（pool_recycle 或者 max_inactive_connection_lifetime）建议设在 300 到 600 秒左右，防止连接僵死。

最后，还有一个最容易被忽略的点：所有 async 数据库操作，必须全程在同一个事件循环中完成。从依赖项获取连接开始，到执行查询，再到返回结果，中间不能穿插任何同步阻塞调用。一旦这个链条断了，所谓的 async 就变成了伪异步，性能很可能还不如精心调优过的同步方案。