max_size设过高会压垮数据库：它代表并发连接上限，若超过postgresql的max_connections（建议≤100并留20%余量）或mysql的70%阈值，将触发“too many connections”；多worker场景下实际连接数为max_size×workers，易被忽略。
asyncpg.create_pool 的 max_size 设太高会直接压垮数据库
max_size 不是“越大越好”，它代表连接池能向 PostgreSQL 同时发起的最大并发连接数。如果设成 50，而你的数据库 max_connections 是 100，那两个服务一跑就占掉一半；再加个备份连接、几个管理会话，立刻触发 Too many connections 错误。
真实压测中常见现象：QPS 拉到 300，max_size=30 时数据库 Threads_connected 稳定在 22 左右；改成 max_size=50 后，同一 QPS 下连接数冲到 48，PG 日志开始刷 connection limit exceeded。
- PostgreSQL 单实例建议总连接数 ≤ 100（含应用池、replication、psql 连接），留至少 20% 余量
- MySQL 要看
max_connections配置，应用池总连接数别超过它的 70% - FastAPI 多 worker 场景下，每个 worker 都有自己的池——实际连接数 =
max_size × workers，这点极易被忽略 - 别按 CPU 核数设
max_size：Python 的 GIL 和 I/O 等待会让真实并发远低于理论值
min_size 太小 + 高频短请求 = 连接反复创建销毁
设 min_size=1 看似节省资源，但在每秒上百次的 API 请求下，连接池频繁扩容缩容，反而引发大量 TCP 握手和认证开销。你会看到日志里反复出现 server closed the connection unexpectedly 或 ConnectionResetError，本质是空闲连接被数据库主动踢出，而池没来得及检测。
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
-
min_size建议设为 5–10，覆盖日常低峰流量，避免冷启动抖动 - 配合
max_inactive_connection_lifetime=300（5 分钟），比依赖pool_recycle更轻量——它只回收真正闲置的连接，不强制刷新全部 - 对 PostgreSQL，开启
tcp_keepalives_idle=60+tcp_keepalives_interval=10，让 OS 层保活，比应用层轮询更可靠 - 禁用
pool_pre_ping=True（SQLAlchemy）或手动 ping：它会在每次取连接前发一条SELECT 1，高频场景下反而增加无谓延迟
没配 command_timeout 导致慢查询拖垮整个池
asyncpg 默认没有单条查询超时。一个 SELECT * FROM huge_table ORDER BY unindexed_col 卡住 30 秒，就会把那个连接锁死 30 秒——如果池里只有 10 个连接，后续 9 个请求全得排队等它释放，形成雪崩。
- 务必显式传
command_timeout=30（单位秒），让查询在超时后自动中断并归还连接 - 这个值要略大于 P95 查询耗时，但不能超过业务最大容忍延迟（比如接口 SLA 是 2s，那就设 1.5s）
- 配合 PostgreSQL 的
statement_timeout参数（如SET statement_timeout = '1500ms'），双保险防漏网 - 别指望靠重试解决：
tenacity重试前必须确认操作幂等，否则超时回滚失败+重试 = 重复扣款
连接没归还池的静默泄漏比报错更危险
最麻烦的不是 TimeoutError，而是连接被取出来用了，但没走 async with pool.acquire() 的上下文路径，或者在异常分支里漏了 await conn.close()。这种泄漏不会立即报错，但连接数会缓慢爬升，直到某天凌晨数据库突然拒绝新连接。
关键检查点：
- 所有
pool.acquire()必须包在async with里，禁止裸调await pool.acquire() - FastAPI 中若用
Depends(get_db)注入连接，确保get_db本身是 async generator 且 yield 前已 acquire，yield 后有 finally close - 监控项比日志更管用：定期查
SELECT count(*) FROM pg_stat_activity WHERE state = 'active'，持续高于max_size × 0.8就说明有泄漏 - 开发期加
echo=True（SQLAlchemy）或log_level=asyncpg.enums.LogLevel.DEBUG，观察 acquire / release 是否成对出现
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
