直接还原必然失败，核心障碍是MariaDB与MySQL在DEFAULT CURRENT_TIMESTAMP语法、utf8mb4字符集支持、sql_mode严格性及TINYINT(1)语义上的实现差异，须手动修改SQL文件并用“运行SQL文件”方式导入。
不存在“无缝迁移”——mariadb 到 mysql 的迁移在 navicat premium 15 中必然涉及手动干预，核心障碍是语法与行为差异，而非工具能力不足。
导出 SQL 文件时必须禁用 MariaDB 特有语法
Navicat 默认导出的 .sql 文件会忠实保留 MariaDB 的特性，比如 DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP（MariaDB 10.3+ 默认启用），但 MySQL 5.6 及更早版本不支持该写法，直接导入会报 ERROR 1067 (42000): Invalid default value。
- 打开导出的 SQL 文件，全局搜索
DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP，全部删掉或替换为具体时间字面量（如'2024-01-01 00:00:00'） - 检查
CREATE TABLE语句末尾的字符集声明：若含CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci，而目标 MySQL 是 5.5 或 5.6，需降级为CHARSET=utf8 COLLATE=utf8_general_ci -
TINYINT(1)在 MariaDB 中常被用作布尔类型，但部分 MySQL 驱动仍按整型解析；建议统一替换成BOOLEAN或加注释说明用途
还原前必须对齐 sql_mode
MySQL 和 MariaDB 对严格模式的默认启用程度不同。MariaDB 通常默认开启 STRICT_TRANS_TABLES 和 NO_ZERO_DATE，而很多生产环境 MySQL（尤其 5.7 之前）仍使用宽松模式，不调整会导致字段默认值校验失败。
- 连接目标 MySQL 后执行
SELECT @@sql_mode;，确认是否包含STRICT_TRANS_TABLES、NO_ZERO_DATE、TRADITIONAL - 临时方案：执行
SET sql_mode = 'NO_ENGINE_SUBSTITUTION';再运行导入（仅本次会话有效） - 长期方案：修改 MySQL 的
my.cnf，在[mysqld]段落中显式设置sql_mode，使其与 MariaDB 导出时实际使用的模式一致
必须用「运行 SQL 文件」而非「查询窗口执行」
Navicat 的「查询」窗口会对大 SQL 文件做客户端分段解析，遇到百万行 INSERT 或含大 BLOB 的语句极易卡死、超时或静默截断；而「运行 SQL 文件」走服务端执行路径，绕过客户端缓冲限制。
- 在 Navicat 中右键目标数据库 → 选择「运行 SQL 文件」→ 指向已修正的 SQL 文件
- 务必取消勾选「执行每个语句前暂停」，否则大批量语句会因人工确认中断
- 若文件 > 10MB，还需同步检查 MySQL 服务端参数：
max_allowed_packet至少设为256M，wait_timeout建议调至28800（8 小时）以上
真正容易被忽略的是：Navicat 的「数据传输」功能虽能跨库搬运数据，但它不处理 DDL 兼容性，也不会自动适配 sql_mode 或字符集降级——它只管把行数据塞进去。结构迁移和约束重建，始终要靠修正后的 SQL 文件来兜底。
