最安全的做法是直接修改 docker run 的 -v 挂载路径；若已挂载，只需复制宿主机数据并更新启动命令中的路径；若未挂载，则必须 mysqldump 导出再导入新容器。
直接改 docker run -v 挂载路径是最安全的做法
如果你的 MySQL 容器是用 docker run 启动的（非 docker-compose），且数据已通过 -v 挂载到宿主机目录，那迁移根本不需要碰容器内文件系统。只要把宿主机旧挂载点的数据复制到新硬盘路径，再改启动命令里的路径即可。
常见错误是试图在容器里改 /var/lib/mysql 目录位置——这没意义，因为容器一重启就还原；真正起作用的是宿主机上被 -v 映射的那个路径。
- 确认当前挂载点：
docker inspect <mysql-container-name> | grep -A 5 "Mounts"，看Source字段值（比如/opt/mysql-data） - 停容器：
docker stop <mysql-container-name> - 用
rsync -avz /opt/mysql-data/ /data2/mysql-data/复制（注意末尾斜杠，避免嵌套） - 改命令重新运行：
docker run -v /data2/mysql-data:/var/lib/mysql ... mysql:8.0
docker-compose.yml 中改 volumes 路径并重建容器
如果你用 docker-compose 管理 MySQL，迁移只需两步：同步数据 + 更新配置。Docker Compose 不会自动识别你手动改了挂载目录，必须显式重建容器才能生效。
关键点在于：不能只改 volumes 路径后 docker-compose up -d，那样旧容器还在用老路径，新容器可能因端口冲突起不来。
- 停服务：
docker-compose down - 同步数据：
rsync -avz ./mysql-data/ /data2/mysql-data/（假设原volumes是./mysql-data:/var/lib/mysql） - 编辑
docker-compose.yml，把./mysql-data改成/data2/mysql-data - 重建：
docker-compose up -d—— 此时新容器才会挂载新路径
没做挂载、数据全在容器内？必须导出再导入
如果启动 MySQL 容器时没加 -v 或 volumes，所有数据都闷在容器可写层里，/var/lib/docker 下对应容器的联合文件系统中。这种情况下无法“迁移目录”，只能逻辑导出再导入。
强行用 rsync 复制容器内部 /var/lib/mysql 是高危操作：InnoDB 文件对一致性极其敏感，未正常关闭就拷贝极易损坏表空间。
- 先导出：
docker exec <mysql-container> mysqldump -u root -p'xxx' --all-databases --single-transaction > backup.sql - 停容器：
docker stop <mysql-container> - 新建带挂载的容器：
docker run -v /data2/mysql-data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=xxx -d mysql:8.0 - 导入：
docker exec -i <new-mysql-container> mysql -u root -p'xxx'
为什么别碰 /var/lib/docker 迁移来迁就 MySQL
有人想“统一管理”，把整个 Docker 数据目录（/var/lib/docker）迁到新盘，再指望 MySQL 容器自动用上更大空间——这完全误解了问题根源。MySQL 占用磁盘空间的主因是它的 data 目录，不是 Docker 自身元数据。
迁移 /var/lib/docker 是重操作：要停所有容器、改 daemon.json、处理权限、验证镜像完整性。而 MySQL 数据本身仍可能继续膨胀，最终又填满新盘。
真正该做的，是让 MySQL 的 /var/lib/mysql 直接落在大容量路径下，其他容器照常运行，互不干扰。
最易被忽略的一点：新挂载目录的属主必须是 mysql 用户（chown -R mysql:mysql /data2/mysql-data），否则容器启动失败，日志里只报 Can't start server: Bind on unix socket 这类模糊错误。
