Django 4.0.4无法透明自动重连MySQL数据库问题咨询

网传的Django自动重连数据库说法不具备普适性，默认配置下长驻自定义进程遇到数据库连接中断时，确实不会自动重建连接，观察到的无限抛错现象是Django数据库连接生命周期的默认设计导致的，不属于配置bug。

• Django没有内置全局生效的、SQL执行异常触发的自动重连机制。所谓"自动重连"的传言，是对两个原生机制的误读：
  1. MAX_CONN_AGE配置仅作用于连接初始化阶段：仅当新建连接前检查到旧连接存活时长超过配置值时，才会替换为新连接，不会在SQL执行抛出连接错误后主动触发重连
  2. 传统HTTP请求场景下的"自动恢复"是生命周期机制的副产物：Django会在每个请求结束时按MAX_CONN_AGE规则回收连接，下一个请求进入时会重新走连接初始化流程，哪怕上一个请求遇到连接断开，新请求也会拿到新建的连接，表现得像自动重连
• 自定义长驻进程不在Django原生HTTP请求/响应生命周期内，不会自动触发每轮任务结束后的连接回收逻辑，数据库连接会一直缓存在本地连接对象中被反复复用。

碰到的两次异常完全符合默认行为逻辑：

1. 首次抛出django.db.utils.OperationalError: (2013, 'Lost connection to server during query')时，TCP层面的连接已经中断，但Django没有把这个连接标记为失效，仍然残存在连接缓存中
2. 后续轮次执行任务时，Django直接复用缓存中已断开的连接对象，没有做任何存活校验就发起SQL请求，因此抛出django.db.utils.OperationalError: (2006, 'Server has gone away')
3. 由于没有手动干预连接状态，失效连接会一直留在缓存中被反复调用，因此会无限循环触发异常，永远无法自行恢复
   关于配置的补充说明：设置的MAX_CONN_AGE=0含义是"HTTP请求结束后立即关闭连接"，该逻辑仅在Django原生请求收尾阶段触发，对自行编写的循环长驻任务没有任何效果——自定义任务流程根本不会触发Django内置的请求结束信号和连接回收逻辑。每秒发起一次请求未触发MySQL默认28800秒的wait_timeout，说明连接不是被MySQL主动断开，大概率是中间链路的网络设备（防火墙、NAT网关）回收空闲连接、或者数据库实例临时重启/主从切换导致的连接中断。

• 最轻量方案：每轮任务执行完成后主动调用django.db.close_old_connections()。这是Django内置的连接回收方法，会自动关闭失效、超龄的连接，下一轮任务执行SQL时Django发现无可用连接会自动新建，从根源避免失效连接被复用
• 异常兜底方案：捕获django.db.utils.OperationalError类的连接相关异常，在异常处理逻辑中调用对应数据库连接的close()方法主动丢弃失效连接，后续数据库操作会自动新建连接
• 全局生效方案：如果使用Django 2.2及以上版本，可自定义数据库后端包装类，在SQL执行抛出连接类异常时自动触发重连重试，不需要在每段业务逻辑里加重复处理，注意不要在每次SQL执行前都加ping校验，避免引入不必要的性能损耗。

内容的提问来源于stack exchange，提问作者aikipooh