直接还原大概率失败，核心问题在于MariaDB与MySQL在字符集、SQL模式、时间类型默认行为上的实现差异；需手动处理DEFAULT CURRENT_TIMESTAMP语法、降级utf8mb4为utf8、调整sql_mode，并用“运行SQL文件”方式导入以避免超时和截断。
直接还原大概率失败，核心问题不在数据库类型切换本身，而在 mariadb 和 mysql 各自版本对字符集、sql 模式、时间类型默认行为的实现差异。不能指望 navicat 自动抹平这些底层不一致。
确认 MariaDB 导出文件是否含 MySQL 不兼容语法
Navicat 默认导出的 SQL 文件会保留源库特性，MariaDB 10.3+ 的 DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 在旧版 MySQL（如 5.6）中不被支持；MariaDB 的 utf8mb4_unicode_ci 排序规则在 MySQL 5.7 中虽存在，但部分子版本（如 5.7.5 之前）对 utf8mb4 支持不完整。
- 用文本编辑器打开备份 SQL 文件，搜索
DEFAULT CURRENT_TIMESTAMP、ON UPDATE CURRENT_TIMESTAMP—— 若目标 MySQL 版本 ≤ 5.6，必须手动删掉或替换为具体时间字面量 - 检查
CREATE TABLE语句末尾是否有ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci这类声明；若目标 MySQL 是 5.5 或更早，需降级为CHARSET=utf8 COLLATE=utf8_general_ci - MariaDB 可能生成
TINYINT(1)表示布尔值，而某些 MySQL 驱动或旧版本会误判为整数范围，建议统一改为BOOLEAN或显式加注释说明
还原前必须调整目标 MySQL 的 sql_mode
MariaDB 默认启用 STRICT_TRANS_TABLES 和 NO_ZERO_DATE，而很多生产环境 MySQL（尤其 5.7 之前）仍用宽松模式。不匹配会导致 ERROR 1067 (42000): Invalid default value for 'created_at' 这类报错。
- 连接目标 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 文件」走服务端执行，绕过客户端缓冲限制。
- 右键目标 MySQL 连接 → 选择「运行 SQL 文件」，而非双击打开后点「运行」
- 检查 Navicat 设置：「工具 → 选项 → 连接 → MySQL」中「查询超时时间」建议设为
0（不限制），否则 300 秒默认值对 >10MB 的 SQL 文件根本不够 - 同步确认 MySQL 服务端参数：
max_allowed_packet至少设为256M（修改my.cnf并重启），否则长文本字段会被截断且无明确错误提示
真正麻烦的不是字符集替换或模式调整，而是 MariaDB 和 MySQL 对同一 SQL 语义的隐式处理差异——比如 TIMESTAMP 字段是否自动补零、ENUM 值大小写敏感性、甚至触发器中 NEW 和 OLD 的可见范围。这类问题不会报错，但数据逻辑会悄悄出错，必须在还原后抽样校验关键字段行为。
