跨平台迁移mysql必须用mysqldump逻辑导出导入，因windows的ibdata1、.ibd等文件受字节序、大小写策略、权限等限制无法在linux直接使用；导出需加--single-transaction、--default-character-set=utf8mb4、--routines --events --triggers，且禁用记事本编辑以防bom导致导入失败。
直接拷贝 Windows 的 data 文件夹到 Linux 会失败
物理文件不能跨平台直接迁移。Windows 下的 ibdata1、.ibd、.frm 等文件在 Linux 上无法被 MySQL 正常识别和加载，原因包括：InnoDB 表空间页格式存在平台相关字节序差异；lower_case_table_names 默认值不一致（Windows 是 1，Linux 是 0），导致表名大小写处理逻辑冲突；文件系统权限、SELinux 上下文、用户 UID/GID 映射全都不匹配。强行替换后启动 MySQL，常见现象是服务卡在初始化阶段、报错 Table 'mysql.user' doesn't exist 或 InnoDB: Operating system error number 13 in a file operation。
mysqldump 是唯一可靠的跨平台物理迁移替代方案
所谓“物理迁移”，在跨 Windows/Linux 场景下实际只能走逻辑导出再导入。关键不是“能不能”，而是“怎么导才不丢东西”。必须满足以下全部条件：
- 导出时加
--single-transaction：避免锁表，保证 InnoDB 数据一致性，否则大库可能因FLUSH TABLES WITH READ LOCK在 Windows 上卡住写入，且该锁在 Linux 导入时超时静默失败 - 显式指定字符集：
--default-character-set=utf8mb4，Windows 客户端默认编码常为cp1252或gbk，不强制声明会导致导出 SQL 中中文变成?或乱码，且无 BOM 校验提示 - 检查并包含数据库对象：
--routines --events --triggers，否则存储过程、事件、触发器全部丢失 - 导出文件禁用记事本编辑：它会悄悄插入 UTF-8 BOM（
ef bb bf），Linux 下执行mysql -u root -p 会直接报 <code>ERROR 1064
导入前必须手动建库并校准字符集与排序规则
不要依赖 mysqldump --databases 自动生成的 CREATE DATABASE 语句。Linux MySQL 默认忽略它，尤其当目标库已存在时，不会校验或更新字符集。结果就是表能建、数据能插，但 SHOW CREATE TABLE 显示 CHARSET=utf8（即 utf8mb3），emoji 插入失败或被截断。正确做法是：
直播话术巡检系统(Windows版) — 实时语音转写、关键词检测、场景自动切换、告警推送、大屏可视化。支持 Windows VB-Cable 虚拟声卡音频采集，阿里云 ASR 实时识别。一键启动脚本，自动安装环境。
- 先登录 Linux 的 MySQL：
mysql -u root -p - 手动创建库：
CREATE DATABASE `mydb` CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; - 导入时也强制客户端编码：
mysql --default-character-set=utf8mb4 -u root -p mydb ，防止终端 locale 影响连接层编码
lower_case_table_names 配置必须提前设好
这是最容易被忽略、又最致命的兼容性开关。Windows 默认 lower_case_table_names=1（不区分大小写），Linux 默认是 0（区分）。如果迁移后没改配置，而原库中有 UserInfo、user_info 这类混合命名的表，MySQL 在 Linux 上可能成功创建，但后续 SELECT * FROM UserInfo 会报错 Table doesn't exist——因为实际文件名是小写的，而查询时按大小写敏感去匹配失败了。解决方法只有一种：在 Linux 的 my.cnf 中 [mysqld] 段落加入：
lower_case_table_names = 1
注意：该参数必须在初始化实例前设置，已运行的实例修改后需重建所有表（ALTER TABLE ... ENGINE=InnoDB）才生效，不能热加载。
