MySQL 5.7 本身没坏，Django 4.0 也不是“不支持”它，而是主动加了一道检查：只要检测到 mysql_version

MySQL 5.7 本身没坏，Django 4.0 也不是“不支持”它，而是主动加了一道检查：只要检测到 mysql_version ，就抛出 <code>NotSupportedError。这不是底层跑不通，是 Django 故意拦下来的。

check_database_version_supported() 是唯一拦路虎

真正阻止 Django 4.x 连上 MySQL 5.7 的，只有这一行代码：self.check_database_version_supported()。它在建立数据库连接后立刻执行，比任何 ORM 操作都早。一旦触发，连 manage.py dbshell 都进不去。

• 这个检查只存在于 django/db/backends/mysql/base.py，不是全局 SQL 兼容性问题
• MySQL 5.7 完全能执行 Django 4.x 生成的绝大多数 SQL（建表、CRUD、JOIN、基本聚合）
• 真正依赖 MySQL 8.0+ 的功能（如 JSON_CONTAINS_PATH、窗口函数、CTE）在 Django 4.x 中默认不启用，除非你显式用 Window 或 With

为什么 Django 要这么干？不是技术限制，是风险控制

Django 团队把版本检查当成一种“安全护栏”，而不是兼容性判决书。背后有三个现实考量：

• mysqlclient 驱动对 MySQL 5.7 和 8.0 的行为差异未完全收敛，比如 DECIMAL 精度解析、TIMESTAMP 默认值处理，在某些 corner case 下会静默出错
• Django 测试矩阵已停止为 MySQL 5.7 运行 CI，意味着新 patch 可能引入仅在 5.7 上暴露的 bug，但没人验证
• 当用户报告“QuerySet.filter(json_field__contains=...) 失败”，Django 维护者没法快速区分是 ORM bug 还是 MySQL 5.7 的 JSON 实现缺陷

绕过检查的实操路径：别改源码，换后端

硬删 check_database_version_supported() 或注释掉它，短期能跑，但下次升级 Django 就得重来。更可持续的做法是替换数据库后端：

python学习

Python 编程学习助手 skill，面向零基础用户。 当用户表达以下意图时触发： - 学习 Python 基础概念（变量、数据类型、循环、函数、类等） - 请求 Python 练习题或测验 - 请求审查或调试 Python 代码 - 请求 Python 项目实战指导（爬虫、数据分析、Web 开发等入门项目） - 泛化表述如"教我 Python""我想学编程""Python 怎么写""帮我学 Python" 此 skill

下载

• 新建包 custom_db_backends/mysql/base.py，继承原 DatabaseWrapper，重写 check_database_version_supported 方法，直接 pass
• 在 settings.py 中把 ENGINE 改成 'custom_db_backends.mysql'
• 确保该模块在 Python path 中可 import，且不被 IDE 或 linter 当作未使用模块删掉

注意：mysqlclient >= 2.0 必须装上，它对 MySQL 5.7 的 socket 通信和字符集支持比旧版稳定得多；如果用 pymysql，Django 4.x 不认它作为正式后端。

立即学习“Python免费学习笔记（深入）”；

真正容易翻车的地方不在版本号上

就算绕过版本检查，MySQL 5.7 用户在 Django 4.x 里最常掉坑的，其实是两个隐形依赖：

• DEFAULT_AUTO_FIELD：Django 4.x 强制要求设置，否则 makemigrations 会持续报 models.W042 警告，且主键类型默认变成 BigAutoField —— 这在 MySQL 5.7 里完全 OK，但如果你旧表主键是 INT，迁移时可能触发 ALTER TABLE 类型变更，需手动干预
• json_field__contains 查询：MySQL 5.7 的 JSON_CONTAINS 函数不支持路径表达式嵌套，Django 生成的 SQL 可能返回空结果而非报错，这种静默失败比报错更难排查