最稳妥推荐方式是用docker volume create创建命名卷并挂载到/var/lib/mysql，因MySQL官方镜像硬编码该路径，挂错则初始化空库、数据写入失败；命名卷由Docker自动处理权限与兼容性，绑定挂载易出SELinux、权限等问题。
直接用 docker volume 创建命名卷，挂载到容器的 /var/lib/mysql，是最稳妥、最推荐的方式。绑定挂载（-v /host/path:/var/lib/mysql）容易因权限、SELinux、文件系统兼容性出问题，不建议新手用。
为什么必须挂载 /var/lib/mysql 而不是其他路径
MySQL 官方镜像硬编码了数据目录为 /var/lib/mysql。你改环境变量、配文件都无效——它启动时只认这个路径。如果挂错位置（比如 /data 或 /mysql），容器会初始化一个空库，但实际数据写不进去，日志里反复报 mysqld: Can't read dir of '/var/lib/mysql/' (Errcode: 2 - No such file or directory)。
常见错误现象：
- 容器反复重启，
docker logs mysql显示权限拒绝或目录不存在 - 首次启动后能连上，但新建数据库、表后重启就消失
-
docker exec -it mysql ls /var/lib/mysql返回空，说明挂载根本没生效
docker volume 和绑定挂载（-v /host/path:/var/lib/mysql）怎么选
命名卷由 Docker 管理，自动处理权限、SELinux 上下文、跨平台兼容性；绑定挂载依赖宿主机目录状态，风险高。
使用场景与差异：
- 开发/测试环境：优先用
docker volume create mysql-data+--mount source=mysql-data,target=/var/lib/mysql，删容器不丢数据，迁移也方便 - 需要直接编辑配置文件或备份脚本读取原始数据文件：才考虑绑定挂载，但必须提前
chown -R 999:999 /host/mysql（MySQL 容器默认以 UID 999 运行），且 SELinux 开启时得加:z或:Z标签，如-v /host/mysql:/var/lib/mysql:z - Windows/macOS Docker Desktop：绑定挂载可能因文件系统缓存导致 MySQL 启动失败，命名卷更稳定
docker-compose.yml 中正确配置 Volume 的写法
别用 volumes: 下的匿名数组写法（如 - ./mysql:/var/lib/mysql），那是绑定挂载，容易踩坑。明确声明命名卷并复用：
version: '3.8'
services:
mysql:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: rootpass
volumes:
- mysql-data:/var/lib/mysql
ports:
- "3306:3306"
<p>volumes:
mysql-data:
driver: local关键点：
-
volumes:顶层定义mysql-data，Docker 会自动创建（如果不存在） - 服务内
volumes:只写mysql-data:/var/lib/mysql，不带路径前缀 - 不要在
volumes:里混用命名卷和绑定挂载，容易混淆 - 首次运行
docker-compose up后，可用docker volume inspect mysql-data查看真实存储路径（通常是/var/lib/docker/volumes/mysql-data/_data）
容易被忽略的权限和初始化细节
即使挂载正确，MySQL 容器第一次启动仍可能失败，原因常不在挂载本身，而在数据目录残留或权限错乱：
- 如果宿主机目录或卷里已有旧数据（比如从其他 MySQL 版本拷过来的），容器会拒绝启动，报错类似
mysqld: File './ibdata1' not found (Errcode: 2)—— 必须清空或确认版本兼容 - 用
MYSQL_ROOT_PASSWORD启动后，再删容器重建，新容器会复用旧数据，但不会重新设密码；如果想重置，得手动进卷目录删掉ib_logfile*和auto.cnf（不推荐，易损坏） - 挂载了卷之后，
MYSQL_DATABASE只在卷为空时生效；如果卷里已有库，该变量会被忽略 - 别给
/var/lib/mysql挂载只读（:ro），MySQL 启动直接失败
真正麻烦的从来不是“怎么挂”，而是挂完之后目录里有什么、谁在读写、权限对不对——这些细节不检查，90% 的“持久化失效”问题都出在这儿。
