mysqldump导出必须加--single-transaction和--default-character-set=utf8mb4，否则Windows客户端编码与Linux服务端utf8mb4不一致会导致中文乱码，且无--single-transaction会触发FLUSH TABLES WITH READ LOCK卡住写入并可能导入失败。
mysqldump导出时必须加--single-transaction和--default-character-set=utf8mb4
Windows 上默认字符集常为 cp1252 或 gbk，而 Linux MySQL 服务端通常默认 utf8mb4；不显式指定，mysqldump 会按客户端环境编码读取表结构和数据，导出 SQL 文件头可能没声明编码，导入时触发二次转码，中文直接变 ? 或乱码。
InnoDB 表若不加 --single-transaction，默认会执行 FLUSH TABLES WITH READ LOCK，在 Windows 上可能卡住业务写入；更关键的是，该锁在 Linux 导入时若超时（尤其大库），mysql 客户端会中断连接，导致部分表导入失败但无明确报错。
- 导出命令务必写全：
mysqldump --single-transaction --default-character-set=utf8mb4 -u root -p mydb > mydb.sql - 避免用记事本保存或编辑 dump 文件——它会悄悄加 BOM（
ef bb bf），Linux 下执行mysql命令时直接报ERROR 1064；可用head -c 3 mydb.sql | xxd检查 - 若库含存储过程、函数或事件，额外加
--routines --events，否则这些对象不会被导出
导入前必须手动建库并指定 utf8mb4 字符集
mysqldump --databases 生成的 SQL 中虽有 CREATE DATABASE 语句，但 Linux MySQL 默认忽略它（尤其当目标库已存在时），也不会校验字符集是否匹配。结果就是：库能创建、表能建、数据能插，但 SHOW CREATE TABLE 显示 CHARSET=utf8（实为 utf8mb3），emoji 插入失败或被截断。
导入命令本身不负责建库，只执行文件内 SQL；如果目标库不存在，mysql -u root -p mydb 会直接报 <code>ERROR 1049 (42000): Unknown database 'mydb'。
- 先登录 Linux 的 MySQL，执行：
CREATE DATABASE `mydb` CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; - 导入时也强制指定客户端编码：
mysql --default-character-set=utf8mb4 -u root -p mydb ，防止 shell 终端 locale 影响连接层编码 - 别用 MySQL 客户端内的
source mydb.sql——大文件易因网络/超时中断，且错误定位困难
lower_case_table_names 是跨平台迁移中最容易静默失败的配置
Windows 默认 lower_case_table_names=1（不区分大小写），Linux 默认是 0（区分大小写）。迁移后若未显式设置，表名含大写字母（如 UserInfo）在 Linux 上能创建、能 SELECT，但后续任何 ALTER TABLE UserInfo ... 或 mysqldump 备份脚本都会失败——报 Table 'userinfo' doesn't exist，因为内部元数据比对时把大小写当成了不同对象。
这个参数在 MySQL 8.0+ 是只读的，改配置 ≠ 重启生效。必须删掉整个 data 目录下的 ibdata1、ib_logfile* 和 mysql/ 子目录（保留 socket 路径结构），再用 mysqld --initialize-insecure 重建数据目录。
- 验证是否真正生效：执行
CREATE TABLE TestTable (id INT);，再运行SHOW TABLES LIKE 'testtable';——有结果才说明大小写已忽略 - 修改位置必须是
my.cnf的[mysqld]段，不能写在[client]或注释掉 - 一旦设为
1，所有新表名自动转小写存盘，旧 dump 文件里带大写的CREATE TABLE语句仍可执行，但实际存为小写
传输后检查换行符与 secure_file_priv 限制
Windows 记事本、PowerShell 默认用 \r\n（CRLF），Linux 用 \n（LF）。虽然 mysql 客户端本身能容忍 CRLF，但若 dump 文件中包含手写触发器、存储过程或 LOAD DATA INFILE 语句，其中的字符串字面量若含隐式换行，Linux 下解析会报语法错误。
另外，某些 GUI 工具（如 Navicat、DBeaver）导出时可能误加 LOAD DATA INFILE，而 Linux MySQL 默认开启 secure_file_priv，该路径外的文件无法加载——导入时卡在某条语句不动，日志却只报 Access denied，非常难排查。
- 传完文件后，在 Linux 上运行：
dos2unix mydb.sql统一换行符（没装则用sed -i 's/\r$//' mydb.sql） - 导入前检查 dump 文件是否含
LOAD DATA INFILE：grep -n "LOAD DATA" mydb.sql；如有，要么删掉对应语句，要么临时关闭secure_file_priv（不推荐生产环境） - 大文件（>500MB）建议压缩传输：
mysqldump ... | gzip > mydb.sql.gz，解压后再导入，减少网络传输错误概率
lower_case_table_names 必须提前规划好值并重建数据目录，而换行符和 secure_file_priv 这类细节，不报错但会让导入中途哑火——得一条条对着日志和文件内容抠。 
