Django向MySQL发送None空查询引发间歇性报错该如何排查解决

Django 本身不会主动执行空查询，你在日志中看到的sql: None记录是异常发生后的结果，不是引发问题的诱因：当数据库连接已经失效时，查询流程还没完成SQL组装就触发了连接异常，connection.queries的记录逻辑拿不到实际执行的SQL内容，才会存储为None值。

你遇到的三类报错（2000 Unknown MySQL Error、InterfaceError、2027 Malformed Packet），结合数分钟自愈、几小时复发的特征，本质都是复用了已经失效的数据库连接，常见触发原因和解决方法如下：

核心触发原因 #

1. Django 2.2 版本的连接复用逻辑存在缺陷：默认会一直复用连接直到被数据库主动断开，不会主动检测连接有效性。如果中间连接被防火墙、负载均衡等网络设备按空闲回收策略掐断，Django会把已经失效的连接当成正常连接使用，就会触发上述报错。等连接池内所有失效连接都被淘汰重建后，服务就会自动恢复。
2. mysqlclient 2.0.3 与 Django 2.2 存在兼容问题：2.0+ 版本的 mysqlclient 对连接状态的判断逻辑和老版本不同，Django 2.2 的连接校验逻辑没有适配该变化，无法识别出已经失效的连接。
3. 你调整的wait_timeout参数不生效：如果网络设备的空闲连接回收时间（一般为30分钟到1小时）比数据库的wait_timeout短，连接会先被网络设备掐断，数据库侧还没到超时时间，因此调整数据库超时参数没有效果。

排查验证方法 #

1. 抓包确认网络回收规则：在应用服务器上用tcpdump抓MySQL端口的数据包，确认是否每隔固定周期就会出现连接被RST的情况，对应你的报错时间点。
2. 临时禁用连接复用验证：将Django数据库配置中的CONN_MAX_AGE设为0，即每次请求结束就关闭连接，观察24小时如果不再报错，即可确定是连接复用导致的问题。

解决方案 #

临时快速修复 #

在Django数据库配置中调整连接存活时间，确保连接在被网络设备回收前主动断开：

DATABASES = {
    'default': {
        # 原有配置保持不变
        'CONN_MAX_AGE': 60, # 取值要小于网络设备的空闲连接回收时间，保守可先设为60秒
    }
}

如果调整CONN_MAX_AGE后仍有报错，可以增加连接健康检测中间件，每次请求执行数据库操作前先校验连接有效性：

from django.db import connection
from django.db.utils import InterfaceError

class DBHealthCheckMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        try:
            connection.cursor().execute("SELECT 1")
        except InterfaceError:
            connection.close()
        return self.get_response(request)

将该中间件放到MIDDLEWARE配置列表的最顶部即可。

永久修复方案 #

1. 优先升级Django到3.2及以上LTS版本：3.2版本修复了大量连接复用相关的缺陷，还内置了CONN_HEALTH_CHECKS参数，无需自己写中间件即可实现连接健康检测。
2. 如果无法升级Django，将mysqlclient降级到1.4.6版本，该版本和Django 2.2的兼容性最好，不存在连接状态判断的兼容问题。
3. 同步调整MySQL的wait_timeout和interactive_timeout参数，取值小于网络设备的空闲连接回收时间，避免网络设备先断开连接。

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