启用STATEMENT格式Binlog时，Django迁移MySQL失败的非配置方案咨询

我之前部署Django项目时也踩过一模一样的坑，当时不想动MySQL的binlog配置，试了几个Django侧的解决方案都能搞定，分享给你：

方案1：全局调整数据库会话的事务隔离级别 #

报错的核心逻辑是：当InnoDB使用READ COMMITTED或READ UNCOMMITTED隔离级别时，MySQL会强制要求用行级（ROW）binlog，但你的binlog是STATEMENT格式，两者冲突导致无法执行语句。

解决思路是把Django的数据库连接会话隔离级别改成REPEATABLE READ（MySQL默认级别）或者SERIALIZABLE，这样InnoDB就不会强制要求行级日志了。

在项目的settings.py里修改数据库配置，添加init_command：

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': '你的数据库名',
        'USER': '数据库用户名',
        'PASSWORD': '数据库密码',
        'HOST': 'localhost',
        'PORT': '3306',
        'OPTIONS': {
            # 每个新连接建立时自动设置会话隔离级别
            'init_command': "SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ",
        },
    }
}

这个配置会在Django每次建立数据库连接时自动执行这条SQL，从根源上避免隔离级别和binlog格式的冲突，属于一劳永逸的方案。

方案2：仅在Migrate时临时切换隔离级别 #

如果你的应用业务必须使用READ COMMITTED隔离级别，不想全局修改配置，可以针对migrate操作单独设置隔离级别：

1. 创建一个临时配置文件，比如settings_migrate.py，继承主配置并修改数据库选项：

from .settings import *

# 仅migrate时使用该隔离级别
DATABASES['default']['OPTIONS']['init_command'] = "SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ"

2. 执行migrate时指定这个临时配置：

python manage.py migrate --settings=你的项目名.settings_migrate

这样只会在迁移数据库时切换隔离级别，完全不影响正常运行的应用服务。

方案3：修改特定迁移文件的操作 #

如果只有某几个迁移文件触发了报错，可以手动修改这些迁移文件，在执行迁移操作前临时设置隔离级别：

打开对应的迁移文件（比如migrations/000x_xxxx.py），添加RunSQL操作：

from django.db import migrations, models

class Migration(migrations.Migration):

    dependencies = [
        # 保留原有的依赖配置
        ('你的应用名', '000x_xxxx'),
    ]

    operations = [
        # 先临时设置会话隔离级别
        migrations.RunSQL("SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ"),
        # 原有的迁移操作，比如添加字段、修改表结构等
        migrations.AddField(
            model_name='你的模型名',
            name='new_field',
            field=models.CharField(max_length=255, null=True),
        ),
    ]

保存后重新执行migrate即可，这个方案适合只需要修复个别迁移的场景。

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