如何将mysql从Windows环境迁移到Linux_逻辑备份与路径兼容处理-mysql教程-PHP中文网

mysqldump导出必须加--single-transaction和--default-character-set=utf8mb4，否则Windows客户端编码与Linux服务端utf8mb4不一致会导致中文乱码，且无--single-transaction会触发FLUSH TABLES WITH READ LOCK卡住写入并可能导入失败。

如何将mysql从windows环境迁移到linux_逻辑备份与路径兼容处理

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 会直接报 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，因为内部元数据比对时把大小写当成了不同对象。

直播间话术巡检-windows

直播话术巡检系统(Windows版) — 实时语音转写、关键词检测、场景自动切换、告警推送、大屏可视化。支持 Windows VB-Cable 虚拟声卡音频采集，阿里云 ASR 实时识别。一键启动脚本，自动安装环境。

下载

这个参数在 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 这类细节，不报错但会让导入中途哑火——得一条条对着日志和文件内容抠。