mysqldump是唯一推荐的跨平台迁移方式；直接拷贝数据文件不可行，因lower_case_table_names默认值差异（windows=1，linux=0）及文件系统大小写敏感性会导致启动失败或表找不到。
mysqldump 是唯一推荐的跨平台迁移方式，直接拷贝数据文件（ibdata1、.frm、.ibd）在 Windows → Linux 场景下**不可行**，会因 lower_case_table_names 默认值差异（Windows=1，Linux=0）和文件系统大小写敏感性导致启动失败或表找不到。
导出时必须显式指定 --default-character-set=utf8mb4 和 --single-transaction
Windows 上 MySQL 客户端默认编码常为 cp1252 或 gbk，而 Linux 服务端普遍用 utf8mb4。不加 --default-character-set=utf8mb4，mysqldump 会按 Windows 客户端编码读取数据，导出的 SQL 文件中中文字段可能已损坏，导入后变 ? 或乱码。
--single-transaction 不只是“避免锁表”——它让 InnoDB 在导出全程基于一致性快照，否则默认触发 FLUSH TABLES WITH READ LOCK，在 Windows 上可能阻塞业务，且该锁在 Linux 导入时若超时，mysql 客户端会静默断连，部分表缺失无提示。
- 正确命令：
mysqldump --single-transaction --default-character-set=utf8mb4 -u root -p mydb > mydb.sql - 若含存储过程/函数/事件，追加
--routines --events - 禁用记事本编辑 dump 文件：它会偷偷插入 BOM（
ef bb bf），Linux 下执行mysql时直接报ERROR 1064；可用head -c 3 mydb.sql | xxd检查
导入前必须手动创建 utf8mb4 数据库，不能依赖 dump 文件里的 CREATE DATABASE
Linux 的 mysql 客户端默认忽略 dump 文件中带 CHARACTER SET 的 CREATE DATABASE 语句（尤其当目标库已存在时），也不会校验字符集是否匹配。结果是：库能建、表能插，但 SHOW CREATE TABLE 显示 CHARSET=utf8（实为 utf8mb3），emoji 插入失败或被截断。
- 先登录 Linux MySQL：
mysql -u root -p - 执行：
CREATE DATABASE `mydb` CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; - 不要用
mysql -u root -p mydb 直接导入——若库不存在，报 <code>ERROR 1049 (42000): Unknown database 'mydb'
导入命令也必须加 --default-character-set=utf8mb4
即使 dump 文件本身是 utf8mb4 编码，Linux 客户端连接 MySQL 时若未指定字符集，仍可能触发连接层二次转码（比如从 latin1 → utf8mb4），导致中文字段被破坏。
- 正确导入：
mysql --default-character-set=utf8mb4 -u root -p mydb - 若文件含
LOAD DATA INFILE语句（某些 GUI 工具误加），需确认 Linux 的secure_file_priv允许该路径，否则报错模糊（如ERROR 13） - 传输后建议用
dos2unix mydb.sql统一换行符，避免 CRLF 在触发器或注释中引发语法歧义
--default-character-set=utf8mb4，或者少执行一次手动建库，后续查数据时中文变问号、emoji 被截断、表名大小写报错，都得重来。
