mysqldump是唯一靠谱的跨平台导出方式，因其输出纯SQL文本，规避字节序、页格式、文件系统等二进制兼容性问题；但需严格统一character-set-server、lower_case_table_names和sql_mode配置，否则导入后应用可能异常。
直接拷贝 ibd 或整个 /var/lib/mysql 目录，跨系统必然失败 —— 不是配置没调好，而是 InnoDB 二进制格式本身就不兼容。
为什么 mysqldump 是唯一靠谱的跨平台导出方式
mysqldump 输出纯 SQL 文本，不携带任何操作系统或 CPU 架构相关元数据。它绕开了字节序、页校验、文件系统属性等底层差异，是 MySQL 官方唯一明确推荐的跨平台迁移路径。
- Linux 上导出的
dump.sql，在 Windows 的 cmd 或 macOS 的 Terminal 里都能用mysql命令原样导入 - 不依赖本地 MySQL 安装路径，也不要求源/目标版本完全一致（但建议主版本相同，如都是 8.0）
- 可精确控制导出内容：加
--routines才导出存储过程，加--events才导出事件调度器，漏了就真没了 - Windows cmd 默认编码是
GBK，不加--default-character-set=utf8mb4很可能把中文导成乱码
导入前必须对齐的三个关键配置
即使 dump 文件没问题，导入后应用连不上、查不到表、存不了中文，大概率是这三项没提前统一：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
character-set-server和collation-server：目标库my.cnf中必须显式设为utf8mb4和utf8mb4_0900_ai_ci（MySQL 8.0）或utf8mb4_unicode_ci（5.7） -
lower_case_table_names：Linux 默认0（区分大小写），Windows/macOS 默认1（强制小写）。若源库在 Windows，目标库在 Linux，又没提前设lower_case_table_names=1并重启，UserOrder表会变成userorder，应用报Table 'db.UserOrder' doesn't exist -
sql_mode：特别是STRICT_TRANS_TABLES和ONLY_FULL_GROUP_BY，源库开着、目标库关着，某些 INSERT 或 GROUP BY 语句会静默失败或结果异常
大表迁移时 --single-transaction 不是万能的
它只对 InnoDB 表起作用，且前提是事务隔离级别为 REPEATABLE READ（默认）。MyISAM 表仍会被锁，而混合引擎库容易踩坑：
- 加
--skip-triggers可跳过触发器导出，避免导入时因权限或定义缺失报错 - 加
--no-tablespaces可防止导出CREATE TABLE ... TABLESPACE语句，这类语句在目标库无对应表空间时会失败 - 超大表（>10GB）建议分表导出：
mysqldump -t -w "id BETWEEN 1 AND 1000000" db_name table_name > part1.sql，再用mysql分批导入 - 导入时禁用唯一键检查和外键约束：
SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;，导入完再恢复，提速明显
Docker 是最省心的跨平台运行方案
如果你能接受容器化，Docker 比任何手动配置都更接近“无缝”：
- 同一
docker-compose.yml在 Windows、macOS、Linux 上启动的 MySQL 实例，行为完全一致 - 用
volumes挂载统一的my.cnf和初始化 SQL，配置和数据逻辑彻底与宿主机解耦 - 镜像选
mysql:8.0.33这类带小版本号的标签，避免mysql:8.0拉到不同 patch 版本导致行为漂移 - 注意：Docker 内部仍是 Linux 环境，所以挂载的 SQL 文件路径、字符集处理逻辑，要按 Linux 规则来，别照搬 Windows 路径习惯
真正难的不是“怎么把数据搬过去”，而是“搬过去之后，应用还是否认得出来”。表名大小写、时间字段精度、JSON 字段解析行为、甚至 GROUP BY 默认排序，都可能在跨平台后悄然变化。这些细节不会报错，但会让业务逻辑在某天凌晨三点开始返回奇怪结果。
