结论是MySQL容器重启丢数据主因是误用匿名卷而非命名卷；使用-v /var/lib/mysql会每次创建新匿名卷，导致MySQL初始化空库，必须改用-v mysql-data:/var/lib/mysql命名卷实现数据持久化。
直接说结论：不是“重启丢数据”，而是“没挂对Volume”——90%的情况，你用的是匿名卷，不是命名卷。
为什么 docker run -v /var/lib/mysql 一重启就丢数据？
这个写法本质是创建匿名卷（anonymous volume），每次 docker run 都会生成一个新卷，旧数据被彻底隔离。容器删了、重启了、甚至只是 docker-compose down & up，都会触发新卷创建，而 MySQL 启动时发现 /var/lib/mysql 是空目录，就会初始化一套全新数据库。
常见错误现象：
- 执行
docker exec -it mysql mysql -uroot -p -e "CREATE DATABASE test"后，docker restart mysql再查，test消失 -
docker volume ls输出里全是随机哈希名（如8a7f2b1e4c9d...），没有你指定的卷名 -
docker inspect mysql | grep Mounts显示"Source": "/var/lib/docker/volumes/8a7f2b1e4c9d.../_data"，而非你可控的路径
必须用命名卷：mysql-data:/var/lib/mysql
命名卷由 Docker daemon 统一管理，生命周期独立于容器。只要卷名固定，无论容器删多少次、重建多少次，数据都在。
实操步骤（复制即用）：
- 提前创建卷：
docker volume create mysql-data - 启动容器时显式挂载：
docker run -d --name mysql -e MYSQL_ROOT_PASSWORD=123456 -v mysql-data:/var/lib/mysql -p 3306:3306 mysql:8.0 - 验证是否生效：
docker volume inspect mysql-data→ 看Mountpoint路径是否存在且非空
关键点：-v 参数左边不能是路径（如 /path/to/data），也不能省略（如 -v /var/lib/mysql），必须是 卷名:容器内路径 格式。
别用绑定挂载（bind mount）跑 MySQL 生产环境
虽然 -v $(pwd)/mysql_data:/var/lib/mysql 看似能持久，但实际踩坑极多：
- 宿主机目录权限不对（MySQL 容器内用
mysql用户运行，宿主机目录需属主为999:999或加--user 999:999） - Mac / Windows 上文件系统不兼容 InnoDB 日志刷盘行为，极易损坏数据
- 目录路径随
pwd变化，docker-compose.yml移动后挂载失效 - 无法跨平台迁移，
docker volume ls看不到，备份恢复难定位
Docker Volume 是 MySQL 的官方推荐方案，docker volume create 创建的卷自动适配宿主机文件系统，并由 Docker 管理 SELinux/AppArmor 权限。
已经用了匿名卷，怎么抢救现有数据？
别删容器！先停服务再导出：
- 停止写入：
docker exec mysql mysqladmin -uroot -p shutdown - 确认当前挂载点：
docker inspect mysql | jq '.[0].Mounts[] | select(.Destination == "/var/lib/mysql")' - 临时挂载到新命名卷：
docker run --rm -v mysql-data:/target -v /var/lib/docker/volumes/xxx/_data:/source alpine cp -r /source/. /target/（把 xxx 替换为你docker volume ls看到的匿名卷 ID） - 清理无用匿名卷：
docker volume rm $(docker volume ls -qf dangling=true)
真正麻烦的不是操作本身，而是很多人在 docker-compose down 前根本没意识到自己挂的是匿名卷——等发现数据没了，连挂载点都找不回。
