先看数据量和停机容忍度，再选迁移路径；直接用mysqldump导出导入适合中小规模。
先看数据量和停机容忍度，再选迁移路径
直接用 mysqldump 导出导入适合中小规模（/var/lib/mysql 目录同步），但要求源目标 MySQL 版本严格一致，否则 ibdata1 和 .frm 文件可能不兼容。
常见错误现象：导入后表存在但查不到数据、报错 Table 'xxx' doesn't exist，往往就是版本不匹配或没同步 ibdata1 文件导致的。
- 确认源容器 MySQL 版本：
docker exec -it mysql8.0 mysql --version - 检查物理机 MySQL 版本是否完全一致（包括小版本号，如
8.0.33≠8.0.32） - 若版本不一致，强制走
mysqldump，哪怕慢也要保证兼容性
用 mysqldump 迁移时，绕不开的权限与字符集坑
mysqldump 默认不导出用户权限和存储过程，且容易因字符集不一致导致中文乱码。物理机 MySQL 的 my.cnf 若没配 default-character-set=utf8mb4，而容器里是 utf8mb4，导入后字段值会变问号或截断。
实操建议：
- 导出时显式指定字符集：
docker exec -i mysql8.0 mysqldump -uroot -p --all-databases --default-character-set=utf8mb4 > all.sql - 导入前在物理机 MySQL 中执行：
SET NAMES utf8mb4;，再 source 文件 - 若需迁移用户和权限，加参数
--skip-triggers --routines --databases mysql（注意：mysql库含权限表，需 root 权限导入）
rsync 同步 /var/lib/mysql 时，必须停库且校验文件完整性
直接 rsync 数据目录看似快，但 MySQL 正在运行时写入缓存未刷盘，会导致 ibdata1、ib_logfile* 和表空间文件状态不一致，启动失败概率极高。
正确步骤：
- 先停容器：
docker stop mysql8.0，再确认进程已退出（docker ps | grep mysql无输出） - 用
docker inspect mysql8.0 | grep -A 10 "Mounts"找到宿主机真实挂载路径，比如/mnt/mysql/data - 同步后，在物理机上用
ls -la /var/lib/mysql/对比文件数量、大小、修改时间；关键文件ibdata1、ib_logfile0必须存在且非零字节 - 物理机启动前，确保
/etc/my.cnf中datadir=/var/lib/mysql且属主为mysql:mysql
验证阶段最容易忽略的是 socket 路径和 SELinux 上下文
物理机启动 MySQL 后能连 127.0.0.1:3306，不代表本地 mysql -u root -p 能通——CentOS/RHEL 默认启用 SELinux，/var/lib/mysql 目录上下文可能被重置为 system_u:object_r:default_t:s0，MySQL 拒绝访问。
查证命令：ls -Z /var/lib/mysql，正常应为 system_u:object_r:mysqld_db_t:s0；修复只需：restorecon -Rv /var/lib/mysql。
另一个隐藏点：Docker 容器内默认用 localhost 解析为 socket 连接，物理机若没配 socket=/var/lib/mysql/mysql.sock 或权限不对，mysql -u root -p 会报 Can't connect to local MySQL server，而不是密码错。
