asyncpg连接池不能仅用create_pool()，因默认不校验连接可用性，空闲连接可能已断开，取用时抛interfaceerror；须显式配置health_check_interval、max_inactive_connection_lifetime及init参数，并在应用生命周期内统一管理池实例。
asyncpg连接池为什么不能直接用create_pool()就完事？
因为create_pool()默认不校验连接可用性，空闲连接可能在归还后已断开，下次取出时直接报asyncpg.exceptions.InterfaceError: connection is closed。必须显式配置健康检查和超时策略。
实操建议：
- 始终设置
min_size=1和max_size=10（根据DB连接数上限调整），避免空池或过载 - 启用
health_check_interval=30（秒），让池定期探测连接存活状态 - 加上
max_inactive_connection_lifetime=300（秒），强制淘汰长期空闲的连接，防止被PostgreSQL的tcp_keepalives_idle踢掉 - 不要省略
init参数：传入一个异步函数，在每次新连接建立后执行SET timezone = 'UTC'等初始化语句
如何安全地在Web请求中复用连接池？
连接池是协程安全的，但不能跨事件循环使用。常见错误是把池对象存在模块全局变量里，却在不同asyncio.run()调用中重复初始化——这会导致多个孤立池、连接泄漏、FD耗尽。
实操建议：
- 池应作为应用生命周期对象管理：FastAPI用
lifespan，Starlette用on_startup/on_shutdown，手动运行则用async with asyncpg.create_pool(...) as pool: - 每个请求内用
async with pool.acquire() as conn:，别手动pool.release(conn)——异常时容易漏释放 - 避免在
__aenter__里创建池，也不要在类实例初始化时创建池，除非你确定该实例绑定唯一事件循环
为什么fetchrow()比fetch()快，但有时反而更慢？
关键不在函数本身，而在结果集大小和内存分配模式。fetchrow()只解析首行，适合“查单条”；fetch()预分配列表并批量解析，适合小结果集（fetch()会一次性吃光内存，而fetch() + async for record in conn.cursor(...):流式处理才真正高效。
实操建议：
- 明确预期结果行数：
fetchrow()用于SELECT ... LIMIT 1，fetch()用于SELECT ... LIMIT 10以内 - 超过百行，改用游标：
async for row in conn.cursor("SELECT * FROM large_table", prefetch=100):，prefetch控制预取批大小 - 别对
fetch()结果做list(result)二次包装——它已经是list了
连接池抛asyncpg.exceptions.TooManyConnectionsError怎么办？
这不是代码写错了，而是PostgreSQL服务端max_connections设得太低，或者客户端并发请求数超过了池容量与数据库限制的交集。asyncpg不会自动限流，它只是如实反映服务端拒绝。
实操建议：
- 先查PostgreSQL：
SHOW max_connections;，再确认当前已用连接：SELECT count(*) FROM pg_stat_activity; - 池的
max_size必须 ≤ (max_connections− 系统预留连接数)，通常留5–10个给replication、monitoring等 - 加一层信号量限流（如
asyncio.Semaphore(8)）比盲目调大max_size更可靠 - 检查是否有连接没被正确归还：比如
acquire()后未进async with块、或await conn.close()误调用
连接池的“高性能”不来自参数调优本身，而来自对连接生命周期、错误传播路径和PostgreSQL服务端约束的同步认知。漏掉health_check_interval或错估max_connections，比写错SQL更容易拖垮整个服务。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
