确认连接数是否真的触达上限

当Django部署后频繁抛出OperationalError: too many connections时，首先应确认是否确实触发了数据库连接数上限。检查MySQL的max_connections参数，通过命令SHOW VARIABLES LIKE 'max_connections'查看当前设置；同时执行SHOW PROCESSLIST观察当前活跃连接数。若活跃连接接近或达到上限，则可能因为连接未及时释放、并发请求过多或连接池配置不当导致。另外，注意Django默认的CONN_MAX_AGE可能导致长连接堆积，需要结合部署环境分析。

这一步是排查的基础。很多情况下，max_connections默认值只有151（MySQL 5.7）或较低值，而你的应用并发量一旦上来，就容易触发这个错误。但不要立刻去改上限，先看活跃连接中是否有大量Sleep连接——如果多数连接处于Sleep状态且用户是django，那问题出在连接回收而非容量不够。

临时调整max_connections的边界

临时缓解连接数不足，可通过修改MySQL配置文件my.cnf中的max_connections值，例如设置为500或更高，但需谨慎评估服务器内存，每个连接会占用约数MB内存。修改后重启MySQL服务生效。如果短期内无法重启，可执行SET GLOBAL max_connections = 500动态调整，但重启后失效。注意：过度增加max_connections可能引发内存不足，建议逐步调整并观察系统资源占用。

这里需要结合你的服务器内存来判断。比如一台2GB内存的机器，每个MySQL连接约占用2-4MB，如果设置max_connections=1000，光连接就可能吃掉2-4GB内存，加上操作系统和其他进程，很容易OOM。稳妥的做法是先算一笔账：max_connections × 每个连接内存 ≈ 预留内存。另外注意，动态调整后要确认SHOW VARIABLES确实生效，但重启MySQL后恢复原值，所以最终还是要改配置文件并重启。如果服务不能随意重启，可以先动态调大，再在低峰期重启。

优化Django应用层面的连接管理

优化Django应用层面的连接管理。检查settings.py中DATABASES的CONN_MAX_AGE，默认0表示每次请求新建连接，改为60（秒）可复用连接，但需配合数据库端的wait_timeout和interactive_timeout。若使用uWSGI或Gunicorn，可配置连接池，例如借助django-db-connection-pool或pymysql的pool功能。同时排查代码中是否存在未关闭的数据库游标，确保每次查询后显式关闭连接。

很多开发者只修改了Django配置而忽略了数据库端限制。例如，将CONN_MAX_AGE设置较大，但MySQL的wait_timeout（默认28800秒）过长可能导致闲置连接占用资源，而连接数未及时释放。另外，使用连接池时，池大小与数据库max_connections需匹配，否则池内等待的请求仍可能堆积。注意：数据库端修改需要同时调整系统ulimit限制，否则MySQL可能无法创建足够多的文件描述符。

这个矛盾很常见：应用层复用了连接，但数据库端超时时间太长，导致连接被占用不释放。建议将wait_timeout和interactive_timeout设为与CONN_MAX_AGE相近的值（比如60-120秒），这样空闲连接能更快被回收。同时，如果用了连接池（比如django-db-connection-pool），池大小要小于等于max_connections减去预留的Django管理连接数，避免池内连接耗尽后新请求仍在排队。

监控连接状况和隐藏坑

通过MySQL命令实时监控连接状况。执行SHOW STATUS LIKE 'Threads_connected'查看当前连接数，执行SHOW STATUS LIKE 'Connections'查看总连接历史。更详细地，查询information_schema.processlist表：SELECT COUNT(*) FROM information_schema.processlist; 或列出各用户连接数：SELECT user, COUNT(*) FROM information_schema.processlist GROUP BY user; 若发现大量Sleep连接且用户为django，则需调整CONN_MAX_AGE或增加连接回收机制。

除了连接数，还要关注文件描述符限制。Linux系统下MySQL进程能打开的文件描述符受ulimit -n限制，如果max_connections设置过大而描述符不足，MySQL会报错无法创建新连接。检查/etc/security/limits.conf或系统服务配置，确保nofile足够（通常设为65535以上）。这一步往往被忽略，却可能成为瓶颈。

回滚与恢复

如果调整后出现性能下降或内存不足，需要回退：将max_connections改回原值，重启MySQL；同时恢复CONN_MAX_AGE和wait_timeout的原始设置。回滚后观察连接数和错误日志，确认问题消失。建议每次调整只改一个参数，并记录变更前后连接数峰值和错误日志。如果问题反复，可能需要从架构层面考虑读写分离或引入消息队列削峰，但这已超出本文范围。