Django配置MySQL utf8mb4字符集不生效 迁移后变utf8原因咨询

Django项目配置MySQL连接时指定字符集为utf8mb4，配置如下：

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        # ...
        'OPTIONS': {
            'charset': 'utf8mb4',
        }
    },
}

执行python manage.py migrate zero、python manage.py reset_db等迁移/重置操作后，MySQL字符集自动从utf8mb4变为utf8，异常状态截图：

临时处理过程 #

最初尝试直接删除Docker数据卷，执行以下命令时操作失败，系统提示xx volume is in use：

docker volume ls
docker volume rm -f xx    # 执行失败，提示卷正在被占用

后续通过以下命令清空关联数据卷后重建服务，问题暂时消失：

docker-compose -f xx.yml down --volumes

对应docker-compose中MySQL服务配置如下：

# ...
services:
  # ...
  db:
    image: mysql:5.7.18
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
# ...

• Docker卷持久化优先级高于容器启动参数
  MySQL 5.7官方镜像的初始化逻辑是：只有挂载的数据卷完全为空、容器首次启动时，才会执行初始化流程，读取command中传入的字符集参数，写入系统库配置、设置全局默认建库字符集。如果卷中残留了之前生成的旧数据（比如首次启动时未加utf8mb4参数，旧的utf8配置已经持久化到卷内的系统库中），后续哪怕修改启动命令加上字符集参数，只要卷未被清空，镜像不会重新执行初始化流程，服务端默认建库字符集仍为旧的utf8。
  直接执行docker volume rm失败的原因很简单：当时MySQL容器仍处于运行/已创建未删除状态，正挂载占用该数据卷，Docker会锁定正在使用的卷禁止删除。docker-compose down --volumes会自动按顺序停止容器、删除关联容器、删除服务绑定的所有数据卷，旧初始化数据被完全清空，下次启动会按传入参数重新初始化，因此问题暂时修复。
• Django重置数据库操作未显式指定建库字符集
  Django配置中OPTIONS.charset=utf8mb4仅控制Django与MySQL建立连接时的连接层字符集，不会作用于CREATE DATABASE建库语句。执行reset_db或migrate zero重建数据库时，如果没有在建库语句中显式指定CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci，会直接使用MySQL服务端当前配置的默认建库字符集，最终导致重置后字符集退回utf8。

• 不要仅通过command传参修改MySQL配置，将自定义my.cnf配置文件挂载到容器内，在配置中明确写死[mysqld]段的character-set-server、collation-server参数，同时配置客户端默认字符集，从服务层固化字符集配置，不受初始化流程、旧残留数据的影响。
• 通过django-mysql扩展或自定义重置命令，在建库逻辑中显式指定utf8mb4字符集，不依赖MySQL服务端的默认配置，从业务代码层锁定字符集规则。

内容的提问来源于stack exchange，提问作者：我要改名叫嘟嘟