Navicat的「数据同步」功能不适用于MySQL与MariaDB跨引擎同步，因其仅比对行内容、不校验DDL兼容性，会原样执行不兼容语法（如DEFAULT CURRENT_TIMESTAMP），导致ERROR 1067等隐性错误；真正可行路径是导出SQL文件→手动清洗语法与字符集→服务端导入。
Navicat 的「数据同步」功能不适用于 MySQL 与 MariaDB 跨引擎同步
直接用 navicat 的 工具 → 数据同步 功能在 mysql 和 mariadb 之间搬运数据，大概率失败或产生隐性错误。这不是操作问题，而是底层引擎差异导致的兼容性断层。
原因很直接：MySQL 和 MariaDB 虽然语法高度相似，但对 TINYINT(1) 的布尔语义、DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP 的支持版本、sql_mode 默认值、甚至 utf8mb4 的 collation 实现细节都不一致。Navicat 的「数据同步」只比对行内容，完全不校验 DDL 兼容性，也不重写语句。
- 它会把 MariaDB 导出的
CREATE TABLE ... DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP原样发给 MySQL，而 MySQL 5.6 及更早版本直接报ERROR 1067 (42000): Invalid default value - 它不会识别
TINYINT(1)在 MariaDB 中实际被当BOOLEAN用，同步到 MySQL 后可能被 ORM 错误解析为整数 - 如果源表用了 MariaDB 特有的
SEQUENCE或VIRTUAL COLUMN，目标 MySQL（尤其 5.7 之前）根本无法建表，同步流程会在第一步就卡死
真正可行的路径：导出 SQL 文件 + 手动清洗 + 服务端导入
跨引擎同步必须放弃「一键同步」幻想，走「导出 → 人工适配 → 服务端执行」三步。关键不是 Navicat 能不能点，而是你敢不敢改 SQL。
操作要点：
- 导出时，在 Navicat 的
导出向导中务必取消勾选包含 CREATE DATABASE和包含 DROP TABLE—— 这些语句在目标库上极易引发权限或锁表问题 - 导出格式选
SQL 文件，编码选UTF8MB4，但导出后立刻用文本编辑器全局搜索：DEFAULT CURRENT_TIMESTAMP、ON UPDATE CURRENT_TIMESTAMP，全部删掉或替换为具体时间如'2024-01-01 00:00:00' - 检查每张表的
CREATE TABLE末尾，若含COLLATE=utf8mb4_unicode_ci而目标 MySQL 是 5.5/5.6，需降级为COLLATE=utf8_general_ci；同时确认ENGINE=InnoDB显式声明（MariaDB 默认可能用Aria） - 导入时，**必须使用
运行 SQL 文件（右键连接 → 运行 SQL 文件）**，而非复制粘贴进查询窗口 —— 大文件在查询窗口里会被客户端分段截断，且不支持max_allowed_packet自适应
导入前必须调的 MySQL 服务端参数
哪怕 SQL 文件改干净了，MySQL 服务端默认限制仍会拦住大文件。这些参数不是可选项，是必调项。
连接目标 MySQL 后，先执行：
SELECT @@max_allowed_packet, @@wait_timeout;
若返回值低于 268435456（256MB）或 28800（8 小时），就得改配置：
- 临时生效（当前会话）：
SET GLOBAL max_allowed_packet = 268435456;、SET GLOBAL wait_timeout = 28800; - 永久生效：编辑
my.cnf，在[mysqld]段落下添加：max_allowed_packet = 256M、wait_timeout = 28800，然后重启 MySQL - 别忘了确认
sql_mode：执行SELECT @@sql_mode;，若含STRICT_TRANS_TABLES或NO_ZERO_DATE，而源 MariaDB 导出时没启用这些，导入前加一句SET sql_mode = 'NO_ENGINE_SUBSTITUTION';
为什么「数据传输」功能也不能跨引擎直用？
Navicat 的 数据传输 功能（右键数据库 → 数据传输）看起来更“智能”，但它本质仍是客户端驱动的逐行 INSERT，底层依赖 JDBC/ODBC 驱动行为。它绕不开两个硬伤：
- 不处理 DDL —— 表结构得你提前手工建好，且字段类型、约束、索引必须严格对齐，否则传输中途报错就中断
- 对
TEXT/BLOB字段或超长字符串，容易触发驱动层的 packet 截断，错误表现为部分行丢失或乱码，且无明确提示 - 它无法跳过主键冲突或唯一索引冲突的记录，默认行为是终止整个批次，而生产环境往往需要「忽略冲突继续」或「更新已存在记录」
真正省事的做法，是只用它传小量测试数据验证字段映射，正式迁移仍回归 SQL 文件清洗+服务端导入——因为只有这条路径，你能看见每一行、每一个字节发生了什么。
