为何MySQL Docker容器会忽略MYSQL_DATABASE环境变量？

问题场景 #

我在Windows 10环境下用下面的docker-compose.yml配置启动MySQL容器，明明指定了MYSQL_DATABASE要创建mydb库，结果启动后却完全没生效：

version: "3.7"
services:
  db:
    container_name: db
    image: mysql
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: "mysql"
      MYSQL_DATABASE: "mydb"
    security_opt:
      - seccomp:unconfined
    volumes:
      - ./supplied/init:/docker-entrypoint-initdb.d/:ro

执行docker-compose up启动后，进入MySQL查看数据库列表：

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| db                 |
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+

完全看不到配置里的mydb，就像MYSQL_DATABASE环境变量被忽略了一样。

排查与解决 #

后来试着修改了docker-compose文件里的服务名和容器名，重新启动后，mydb居然正常创建出来了！这才反应过来是Docker的缓存/旧数据卷在搞鬼。

原因拆解

MySQL官方镜像的初始化逻辑有个关键点：只有当容器第一次启动，且挂载的数据卷是空的状态时，才会执行MYSQL_DATABASE、MYSQL_USER这些环境变量对应的初始化操作，同时运行/docker-entrypoint-initdb.d/下的脚本。如果之前已经启动过同名容器，而且数据卷没被清理，再次启动时Docker会复用旧的数据卷，初始化逻辑根本不会重新触发，新的环境变量自然就无效了。

通用解决办法

除了改服务/容器名的方式，更直接的处理是彻底清理旧容器和关联数据卷：

1. 停止并删除容器及绑定的卷：

   docker-compose down -v
   

   这里的-v参数会删掉容器挂载的匿名卷和命名卷，确保下次启动是完全全新的环境。
2. 重新启动容器：

   docker-compose up -d
   

总结 #

要是遇到MySQL容器初始化配置不生效的情况，先检查有没有没清理的旧数据卷——这是这类问题最常见的根源。要么彻底清掉旧容器和卷，要么改个服务/容器名让Docker创建全新实例，就能解决大部分初始化失效的问题。

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