导出 MariaDB 数据至 MySQL 必须用 mysqldump 加 --compatible=mysql57 参数，并清洗 ENGINE=Aria、COMMENT 等专属语句，同时调低 MySQL 的 sql_mode 以兼容 0000-00-00 日期，否则导入会失败或乱码。
导出 MariaDB 数据时必须用 mysqldump 加上 --compatible=mysql57
直接执行 mysqldump -u root -p database_name > backup.sql 会导致导入 MySQL 时出现语法错误，比如 ROW_FORMAT=COMPRESSED、STATS_PERSISTENT=0 这类 MariaDB 特有参数被原样导出，MySQL 会报 ERROR 1064。关键不是“能不能导”，而是“导出来的 SQL 能不能被 MySQL 执行”。
正确做法是强制兼容 MySQL 5.7 语法（MySQL 8.0 兼容性更差，先降级适配）：
mysqldump -u root -p --compatible=mysql57 --default-character-set=utf8mb4 --skip-triggers --skip-routines --skip-events database_name > backup.sql
-
--skip-triggers和--skip-routines是为了绕开 MariaDB 存储过程/触发器中可能含有的IF NOT EXISTS或OR REPLACE等非标准写法 -
--default-character-set=utf8mb4避免导出文件里混入utf8（MySQL 的utf8实为utf8mb3），否则导入后中文变问号 - 别用宝塔自带的“数据库备份”功能——它不支持传参，导出内容不可控
MySQL 安装后要手动调低 sql_mode 才能导入成功
MariaDB 默认 sql_mode 比较宽松，而 MySQL 5.7+ 默认启用了 STRICT_TRANS_TABLES 和 NO_ZERO_DATE，遇到 0000-00-00 日期或隐式类型转换就会中断导入。
在 MySQL 配置文件（通常是 /etc/my.cnf 或 /www/server/mysql/etc/my.cnf）的 [mysqld] 段下加一行：
sql_mode = "ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
注意：删掉 NO_ZERO_IN_DATE 和 NO_ZERO_DATE ——MariaDB 导出的数据里很可能存在这类值。改完重启 MySQL：systemctl restart mysqld。
- 不改
sql_mode，导入中途卡住且无明确报错，只显示 “Query OK, X rows affected” 后就停住 - 宝塔面板的 MySQL 管理页里看不到
sql_mode实时值，要用命令确认：mysql -u root -p -e "SELECT @@sql_mode;"
导入前手动清理 backup.sql 里的 MariaDB 专属语句
即使加了 --compatible=mysql57，mysqldump 仍可能保留 ENGINE=Aria、TRANSACTIONAL=1、COMMENT='xxx' 等 MySQL 不识别的字段。这些不会报错但会导致表创建失败或引擎回退成 MyISAM（尤其在低配机器上）。
用 sed 快速清洗（Linux 终端执行）：
sed -i 's/ ENGINE=Aria/ ENGINE=InnoDB/g; s/ TRANSACTIONAL=1//g; s/ PAGE_CHECKSUM=1//g; s/ COMMENT=[^ ]*//g' backup.sql
- 重点替换
ENGINE=Aria→ENGINE=InnoDB，Aria 引擎 MySQL 根本不认识 - 删掉所有
COMMENT=后面的字符串（包括引号），避免因注释含单引号引发语法断裂 - 别用宝塔文件管理器在线编辑大 SQL 文件——容易编码损坏或超时中断
导入时用 mysql 命令行而非宝塔“还原数据库”按钮
宝塔的还原功能本质是调用 mysql，但它加了超时限制和缓冲处理，面对百 MB 级 SQL 文件极易假死或静默失败，且错误日志不返回给用户。
推荐方式（终端执行，带进度提示）：
mysql -u root -p --default-character-set=utf8mb4 database_name < backup.sql 2>&1 | grep -E "(ERROR|Warning)"
- 加上
--default-character-set=utf8mb4是防止客户端连接层编码不一致，导致乱码 - 用
2>&1 | grep实时捕获错误，比等全部执行完再查日志快得多 - 如果中途断开，用
head -n 10000 backup.sql | tail -n 50查最后几条建表语句，定位卡在哪张表
切换本身没有魔法，真正耗时间的是数据校验与兼容性缝合。最常被忽略的是：MariaDB 的 utf8mb4_unicode_ci 排序规则在 MySQL 中虽存在，但行为略有差异，上线后得立刻查几个带 emoji 或生僻字的字段是否显示正常。
