mysqldump是MySQL跨平台迁移的事实标准逻辑工具，生成可读SQL文件，支持--single-transaction保证一致性、--routines--triggers--events保留业务逻辑、--default-character-set=utf8mb4防乱码，禁用--lock-tables避免冗余锁表。
MySQL 没有官方“数据泵”（Data Pump）技术——这是 Oracle 数据库的专有工具名。直接套用该术语容易误判工具链，导致选错命令、查错文档、踩进兼容性深坑。
mysqldump 是 MySQL 跨平台迁移的事实标准逻辑工具
它生成可读 SQL 文件，不依赖源/目标操作系统类型（Linux/Windows/macOS），也不绑定特定 MySQL 安装路径或二进制格式，天然适配跨平台场景。
- 必须加
--single-transaction：对 InnoDB 表保证一致性快照，避免导出过程中数据变更导致主键冲突或丢失 - 务必带上
--routines --triggers --events：否则存储过程、触发器、事件调度器全部丢失，业务逻辑断裂 - 禁用
--lock-tables（默认开启）：它会全局锁表，阻塞写入；而--single-transaction已足够，再加锁纯属冗余且伤业务 - 导出时显式指定字符集：
--default-character-set=utf8mb4，防止客户端环境差异导致乱码（尤其 Windows cmd 默认是 gbk）
物理文件复制不可直接用于跨平台迁移
直接拷贝 /var/lib/mysql/your_db/ 下的 .ibd 和 .frm（或 .sdi）文件，在 Linux → Windows 或不同 MySQL 版本间大概率失败。
- InnoDB 表空间文件（
.ibd）含平台相关字节序和页校验，Windows 上 MySQL 无法加载 Linux 生成的.ibd - MySQL 5.7 及以后用
.sdi替代.frm，其序列化格式与版本强绑定，跨版本复制必报错Tablespace is missing for table xxx - 即使同版本+同架构，
lower_case_table_names设置不一致（如 Linux 默认 0，Windows 默认 1）会导致表找不到
真正能接近“零停机”的跨平台方案只有主从复制
不是靠“泵”，而是靠 binlog 流式同步。它绕过逻辑导出/导入瓶颈，也规避物理文件平台限制，但要求源库开启 binlog 且目标库能解析其格式。
- 源库必须设
server-id=1并启用log-bin；目标库设不同server-id，且binlog_format=ROW（推荐，避免函数/临时表等语句级不安全） - 首次同步需用
mysqldump --master-data=2 --single-transaction导出，其中--master-data=2会在 dump 文件开头写入CHANGE MASTER TO所需的 binlog 坐标 - 导入后在目标库执行
START SLAVE;，它会自动从 dump 记录的位置开始拉取 binlog，实现增量追平 - 切换前停写源库几秒，确认
Seconds_Behind_Master = 0后再切流量，停机控制在秒级
跨平台迁移最易被忽略的点，是把“平台无关”想得太简单：同一份 mysqldump 在 Windows 上用 mysql -u root -p 执行，可能因换行符（CRLF vs LF）或默认字符集（Windows cmd 的 active code page）导致中文变问号；而这些细节，不会出现在任何“数据泵”教程里。
