逻辑迁移适合绝大多数跨平台、版本不一致或需部分导出的场景；物理迁移仅适用于数据量极大（>100gb）、停机窗口极短且源目标环境完全一致的情况。
逻辑迁移适合绝大多数跨平台、版本不一致或需部分导出的场景；物理迁移只在数据量极大（>100GB）、停机窗口极短、且源目标环境完全一致时才值得考虑。
什么时候必须用 mysqldump 做逻辑迁移
当你要从 Windows 迁到 Linux、MySQL 5.7 迁到 8.0、或者只导出某几张业务表时，mysqldump 是唯一稳妥的选择。它不依赖文件系统或 InnoDB 内部结构，只生成标准 SQL，兼容性最强。
- 加
--single-transaction：避免锁表，保障线上读写不受影响 - 显式指定库名，别用
--all-databases—— 否则会把mysql系统库也导进去，目标库权限体系可能直接崩掉 - 含 BLOB/TEXT 字段的表，务必加
--hex-blob，否则传输中二进制数据容易被截断或乱码 - 导入前手动执行
SET FOREIGN_KEY_CHECKS = 0;，导入完再设回1；dump 文件里自带的开关常因注释或分隔符失效 - 从高版本往低版本迁（如 8.0 → 5.7），必须加
--skip-definer和--set-gtid-purged=OFF，否则 JSON 字段定义、角色语法、GTID 相关语句全报错
物理迁移不是“复制文件夹”，而是一次环境对齐手术
物理迁移本质是把 ibdata1、ib_logfile*、所有数据库子目录（如 myapp_db/）、mysql/、performance_schema/ 整套搬过去，并要求目标端的 MySQL 版本、配置、文件系统都严丝合缝。稍有偏差，mysqld 启动就失败。
- 源库必须彻底停止：
systemctl stop mysql，否则缓冲池未刷盘，文件处于不一致状态 -
innodb_page_size必须为默认16KB；innodb_data_file_path只能是ibdata1:12M:autoextend，多一个文件或改个名字（比如ibdata01）就无法加载 - 目标端
my.cnf中innodb_file_per_table、character-set-server等关键参数必须与源端一致，否则启动时拒绝挂载表空间 - 文件属主必须是
mysql:mysql，目录权限不能是777—— MySQL 启动时会校验，过宽直接拒绝 - 仅支持 XFS/ext4；Btrfs/ZFS 上拷贝需额外加
rsync --sparse或--reflink=auto
数据量超过 10GB 就该换工具，别硬扛 mysqldump
mysqldump 是单线程，导出快但导入极慢，尤其面对千万级单表。10GB 是临界点，超过这个量级，mydumper/myloader 的并行能力立刻体现价值。
-
mydumper支持按表并发导出，myloader支持按库/表并发导入，速度通常比mysqldump+source快 3–5 倍 - 导出结果是多个 SQL 文件（每张表一个），便于分片验证、跳过坏表、或只重导某几张
- 不支持触发器、存储过程的自动重建，需额外导出
SHOW CREATE PROCEDURE等语句补全 - 导入前仍要处理外键：
SET FOREIGN_KEY_CHECKS = 0;不可省略
真正容易被忽略的是迁移后的验证——不是看 SHOW TABLES 有没有表，而是批量跑 COUNT(*) 对比每张表的行数。哪怕只差一行，都得查 binlog 或主从延迟日志定位漏数据点。物理迁移后更要核对 information_schema.TABLES.TABLE_ROWS 统计值，误差超 5% 就得重来。
