结构同步前必须确认字符集与排序规则兼容：Navicat仅比对DDL中CHARSET/COLLATE字符串，不校验语义兼容性；MariaDB的utf8mb4在MySQL≤5.6可能报错，需提前验证服务端支持并手动替换；TINYINT(1)与BOOLEAN、sql_mode差异（如STRICT_TRANS_TABLES）亦须人工核对并修改DDL。
结构同步前必须确认字符集与排序规则是否兼容
Navicat 的「结构同步」功能本身不校验字符集语义兼容性，它只会原样比对 DDL 中的 CHARSET 和 COLLATE 字符串。MariaDB 默认导出 utf8mb4_unicode_ci，而 MySQL 5.5/5.6 可能未启用 utf8mb4 支持，直接同步会触发 Unknown character set: 'utf8mb4' 错误。
- 先在目标 MySQL 执行
SHOW VARIABLES LIKE 'character_set%';和SHOW COLLATION WHERE Charset = 'utf8mb4';，确认服务端真正支持的范围 - 若目标 MySQL 版本 ≤ 5.6，需提前在 Navicat 导出 MariaDB 结构时手动禁用
utf8mb4：导出设置 → 勾选「自定义导出」→ 取消勾选「导出字符集声明」，再手动替换所有utf8mb4为utf8 - 注意
utf8在 MySQL 中实际是utf8mb3，不支持 emoji；如需保留，必须升级目标 MySQL 至 5.7+ 并确保innodb_large_prefix=ON
如何识别并绕过 TINYINT(1) 与 BOOLEAN 的语义冲突
MariaDB 将 TINYINT(1) 视为布尔别名，但 MySQL（尤其 5.7 之前）仅按数值类型处理，Navicat 结构同步时不会自动转换，会导致后续应用读写逻辑错乱。
- 在「结构同步 → 比较」界面中，重点查看类型列标注为
TINYINT(1)但源为 MariaDB、目标为 MySQL 的字段——这类字段常被标为「差异」，但 Navicat 默认生成的 DDL 仍保留TINYINT(1) - 点击「部署脚本」选项卡，手动将所有
TINYINT(1)替换为BOOLEAN（MySQL 5.0.12+ 支持）或TINYINT（去掉括号，避免误导） - 更稳妥的做法：同步前在 MariaDB 源库执行
ALTER TABLE tbl MODIFY col BOOLEAN;，让导出 DDL 显式带BOOLEAN类型，Navicat 能正确映射
sql_mode 差异导致的 DEFAULT 值校验失败怎么提前暴露
Navicat 结构同步不检查 sql_mode 对默认值合法性的影响。MariaDB 导出含 DEFAULT CURRENT_TIMESTAMP 的字段，在 MySQL 5.6 及更早版本中会因 STRICT_TRANS_TABLES 缺失而插入空值，但结构同步阶段不会报错——问题只在后续数据写入时爆发。
- 务必在同步前，分别在源（MariaDB）和目标（MySQL）执行
SELECT @@sql_mode;，对比是否都包含STRICT_TRANS_TABLES、NO_ZERO_DATE - 若目标 MySQL 缺失严格模式，不要依赖 Navicat 自动生成的 DDL；应在「部署脚本」中手动删掉所有
DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP，改用具体时间字面量（如DEFAULT '2024-01-01 00:00:00'） - Navicat 的「部署选项」里勾选「遇到错误时继续」毫无意义——这类 DEFAULT 校验失败属于 DDL 执行级错误，会直接中断整个同步流程
为什么不能直接用「数据传输」代替结构同步
「数据传输」功能在 Navicat 中看似快捷，但它完全跳过结构一致性校验，底层走的是 INSERT SELECT 或批量 LOAD DATA，对类型隐式转换、字符集自动降级、默认值填充等行为不可控，极易造成静默数据损坏。
- 例如 MariaDB 的
ENUM('a','b','c')同步到 MySQL 时，若目标列定义为VARCHAR(10)，「数据传输」会照单全收，但 Navicat 不提示你丢失了约束 - 「数据传输」无法处理视图、存储过程、触发器等对象的跨引擎语法差异，而「结构同步」至少能列出这些对象的差异并允许你逐个审查 DDL
- 真正需要迁移时，应严格遵循：先用「结构同步」修正并部署兼容 DDL → 再用「数据同步」搬运数据 → 最后人工校验关键字段（尤其是时间、布尔、枚举类）
sql_mode、字符集变量）。你看到的“无差异”，可能只是表名和字段名一致，而底层行为早已分道扬镳。 
