Django默认不带连接池，CONN_MAX_AGE仅实现进程内连接复用，无法限制总连接数；高并发必须使用第三方连接池（如django-db-connection-pool），否则易触发“too many connections”错误。
直接说结论：Django 默认不带连接池，CONN_MAX_AGE 只是连接复用，不是池；真要扛高并发，必须上第三方连接池，比如 django-db-connection-pool。
为什么 CONN_MAX_AGE 不等于连接池？
Django 的 CONN_MAX_AGE 控制的是单个 Worker 进程内连接的“空闲存活时间”，比如设为 60，意思是这个进程里某个连接空闲 60 秒后才关。但它不控制总连接数，也不跨线程/协程复用——每个新请求仍可能新建连接，直到达到进程最大并发数。Gunicorn 启 4 个 Worker、每个最多处理 20 个并发请求，数据库连接数就可能飙到 80+，远超 RDS 默认 100 的限制。
常见错误现象：django.db.utils.OperationalError: FATAL: remaining connection slots are reserved for non-replication superuser connections 或 too many connections，基本就是这原因。
-
CONN_MAX_AGE = 0：每次请求都新建+关闭，安全但慢，QPS 上不去 -
CONN_MAX_AGE = None：连接永不释放，容易因网络闪断导致“连接已关闭但 Django 不知道”，后续查询直接报错 -
CONN_MAX_AGE = 60：折中，但仍是进程级复用，无法限流、无法回收异常连接
怎么用 django-db-connection-pool 配连接池？
这是目前最轻量、兼容性最好、文档最清晰的 Django 专用连接池方案，底层基于 DBUtils.PooledDB，支持 PostgreSQL 和 MySQL。
立即学习“Python免费学习笔记（深入）”；
安装：
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
pip install django-db-connection-pool
配置（以 PostgreSQL 为例）：
DATABASES = {
'default': {
'ENGINE': 'django_db_connection_pool.backends.postgresql',
'NAME': 'mydb',
'USER': 'myuser',
'PASSWORD': 'mypass',
'HOST': 'localhost',
'PORT': '5432',
'POOL_OPTIONS': {
'POOL_SIZE': 15,
'MAX_OVERFLOW': 10,
'RECYCLE': 300,
'TIMEOUT': 30
}
}
}
关键参数说明：
-
POOL_SIZE：池中常驻连接数，建议设为预估峰值并发的 1.2–1.5 倍（比如平均 QPS 100，Worker 数 4，则 15 是合理起点） -
MAX_OVERFLOW：紧急时最多额外创建多少连接，必须 ≤ 数据库max_connections减去其他服务占用数 -
RECYCLE：连接强制回收时间（秒），避免长连接因数据库侧tcp_keepalive或wait_timeout被静默断开 -
TIMEOUT：从池里取连接的最大等待时间，超时抛queue.Empty，需在业务层捕获并降级
MySQL 和 PostgreSQL 的配置差异在哪？
引擎路径不同，其他参数逻辑一致，但推荐值有区别：
- MySQL 引擎名用
django_db_connection_pool.backends.mysql，PostgreSQL 用django_db_connection_pool.backends.postgresql - MySQL 的
RECYCLE建议 ≤ 280 秒（比 MySQL 默认wait_timeout=28800小 10 秒，留缓冲） - PostgreSQL 的
POOL_SIZE可稍大（15–30），因为其连接开销比 MySQL 略低，且更依赖shared_buffers配置 - 两者都**必须**确保底层驱动已安装：
psycopg2-binary或pymysql/mysqlclient
漏装驱动或写错引擎路径，Django 会 fallback 到默认引擎，POOL_OPTIONS 完全无效，且无任何提示——这是最容易被忽略的坑。
连接池上线后还要注意什么？
连接池不是设完就万事大吉。它把连接生命周期从“请求级”拉长到了“进程级+池级”，带来新问题：
- 事务未提交或连接未归还，会导致连接被长期占用，
MAX_OVERFLOW很快耗尽 - 异步视图（如
async def）或 gevent 环境下，需确认连接池是否线程/协程安全——django-db-connection-pool默认只支持 threading，gevent 用户得换django-db-geventpool - 没配
RECYCLE或设得过大，连接可能被数据库端主动踢掉，Django 下次用时才发现已断，报server closed the connection unexpectedly - 连接池状态没法直接看，建议加一层简单监控：比如用
len(pool._pool)（非公开属性，仅调试）或日志记录getconn/putconn频次
真正难的不是配参数，而是让连接“借了还、错了清、超时收”——这得靠代码规范和少量中间件兜底，而不是光靠池子本身。
