Docker 中 MySQL 容器若通过 volume 挂载了宿主机目录（如 /var/lib/mysql），则初始化环境变量（如 MYSQL_DATABASE、MYSQL_USER）仅在首次初始化空数据目录时生效；重复启动时会跳过初始化，导致修改的数据库名、用户密码等配置不生效。
docker 中 mysql 容器若通过 volume 挂载了宿主机目录（如 `/var/lib/mysql`），则初始化环境变量（如 `mysql_database`、`mysql_user`、`mysql_password`）仅在首次初始化空数据目录时生效；重复启动时会跳过初始化，导致修改的数据库名、用户密码等配置不生效。
当你使用 volumes 将宿主机路径（例如 ../../../../_local_mysql_data:/var/lib/mysql）挂载到 MySQL 容器的 /var/lib/mysql 目录时，Docker 会复用该目录中已存在的数据文件和系统数据库（如 mysql、information_schema）。MySQL 官方镜像的设计逻辑是：仅当 /var/lib/mysql 目录为空时，才执行基于环境变量的初始化流程（创建用户、数据库、设置密码等）；一旦该目录包含有效数据（哪怕只是旧版本残留），后续所有 docker-compose up 或 docker run 均直接启动已有实例，完全忽略你新配置的 MYSQL_* 环境变量。
因此，你修改 docker-compose.yml 中的 MYSQL_DATABASE: big-website-2014 和 MYSQL_USER: test 后仍无法登录，根本原因并非配置错误或网络问题，而是 MySQL 仍在加载旧数据目录中的 mysql.user 表和 mysql.db 表 —— 这些表里仍保存着原始的 gotest 用户与旧库信息。
✅ 正确解决步骤如下：
Docker Hub (hub.docker.com)。此技能适用于所有 Docker Hub 操作，包括读取、创建、更新和删除数据。只要任务涉及 Docker Hub，就使用此技能。
-
彻底清理挂载的数据目录（关键！）
删除宿主机上被挂载的持久化目录：rm -rf ../../../../_local_mysql_data
⚠️ 注意：此操作将永久删除所有现有数据库和用户数据。如需保留数据，请先用
mysqldump备份（见下方提示）。 -
重建容器并初始化新配置
清理后重新构建并启动服务：docker-compose down -v # 确保移除匿名卷（如有） docker-compose up -d --build
-
验证新配置是否生效
连接 MySQL 并检查：docker exec -it <container_name> mysql -utest -ptest -e "SHOW DATABASES;" # 应看到 'big-website-2014' 而非旧库名
? 最佳实践建议：
- 开发阶段如需频繁重置环境，可改用命名卷（named volume）替代相对路径挂载，便于统一管理与清理：
volumes: - db_data:/var/lib/mysql volumes: db_data: # 在顶层 volumes: 下声明
- 生产环境务必在清理前备份：
docker exec <db_container> mysqldump -uroot -ptest --all-databases > backup.sql
- 避免使用
../../../类型的深度相对路径挂载，易引发路径歧义与权限问题；推荐使用绝对路径或 Docker Compose 的./相对根路径。
总结：MySQL 容器的初始化是“一次性契约”——环境变量只在数据目录为空时兑现。挂载卷赋予了数据持久性，也带来了配置隔离性。理解这一机制，是驾驭 Docker 化数据库的关键前提。
