容器删除不等于数据丢失，只要mysql容器曾挂载持久化卷（绑定挂载或命名卷），数据仍存于宿主机；需通过docker inspect或docker volume inspect确认挂载路径，再用原路径启动新容器恢复。
确认数据是否还在宿主机上
容器删了不等于数据丢了——只要当初挂载了持久化卷，数据就还在宿主机磁盘上。关键看两点：/var/lib/mysql 是否被 -v 映射到了宿主机目录，或者用了命名卷。
- 查挂载点：运行
docker inspect -f '{{ range .Mounts }}{{ .Source }} -> {{ .Destination }}{{"\n"}}{{ end }}' mysql-container（把mysql-container换成你原来的容器名）；如果输出为空，说明没挂载，数据大概率已丢失 - 查命名卷：运行
docker volume ls，找名字里带mysql或你自定义名的卷；再用docker volume inspect mysql-data看Mountpoint路径，那就是数据实际存放位置 - 直接进宿主机路径看看：比如
/opt/docker/mysql/data或/var/lib/docker/volumes/mysql-data/_data，ls 一下有没有ibdata1、mysql目录等文件
用原数据目录重建容器
这是最轻量、最可靠的恢复方式，前提是宿主机上的数据目录完整且权限正确（MySQL 进程需能读写）。
- 停掉残留容器（如有）：
docker stop mysql、docker rm mysql - 启动新容器时必须复用原路径：
docker run -d --name mysql -e MYSQL_ROOT_PASSWORD=xxx -v /opt/docker/mysql/data:/var/lib/mysql -p 3306:3306 mysql:8.0（路径和镜像版本要和原来一致） - 注意权限：如果启动失败报
Permission denied，进宿主机执行chown -R 999:999 /opt/docker/mysql/data（MySQL 官方镜像默认用 UID 999 的mysql用户） - 别跳过验证：容器起来后，
docker exec -it mysql mysql -uroot -pxxx -e "SHOW DATABASES;"，确认库名和表结构都在
用命名卷恢复时要小心路径覆盖
命名卷本身是 Docker 管理的抽象层，不能直接 cp 替换内容，但可以“迁移”数据到新卷再挂载。
- 创建新卷：
docker volume create mysql-restored - 用临时容器把旧卷数据拷过去：
docker run --rm -v mysql-data:/from -v mysql-restored:/to alpine tar cf - -C /from . | tar xf - -C /to（把mysql-data换成你原来的卷名） - 启动容器时挂载新卷：
docker run -d --name mysql -v mysql-restored:/var/lib/mysql ... - 切记不要在新卷非空时直接挂载启动 MySQL，否则会初始化空库，覆盖原有数据
mysqldump 备份文件导入不是万能解药
如果你只有 backup.sql，那它只是逻辑备份，无法还原系统库、用户权限、存储过程等，更不能替代物理数据目录的完整性。
- 导入前先建库：
docker exec -it mysql mysql -uroot -p123456 -e "CREATE DATABASE IF NOT EXISTS myapp CHARACTER SET utf8mb4;" - 再导入：
docker cp backup.sql mysql:/tmp/ && docker exec -i mysql mysql -uroot -p123456 myapp - 常见坑：
mysqldump导出时没加--routines就没存储过程；没加--triggers就没触发器；字符集不一致会导致乱码 - 真正重要的不是“能不能导入”，而是“导入后业务表数据是否全、主键是否连续、外键约束是否生效”——这些都得手动核对
恢复这件事，核心永远是“数据在哪”和“权限对不对”。别信“删了容器还能一键还原”的说法，Docker 不负责数据保护，它只管进程隔离。你看到的 /var/lib/mysql 在容器里，但它的真身早就在宿主机某个角落躺着了——找到它，再喂给新容器，这事才算完。
