使用navicat结构同步前，须先验证源库和目标库连接可用性及元数据访问权限，确认information_schema查询与show create table可执行，再正确设置源（开发库）与目标（生产库）顺序，避免方向错误。
用 navicat 的「结构同步」前，先确认两边连接是否真正可用
很多“比对失败”其实不是功能问题，而是连接本身不可靠。navicat 的结构同步依赖完整元数据读取，若生产库开启了严格权限控制（比如只给 select 权限、禁用 show create table 或 information_schema 查询），结构同步 会静默跳过某些表，甚至直接报错 access denied for user 或 table doesn't exist in target。
实操建议：
- 在两个连接上分别手动执行
SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'your_db_name';，确认能查出一致的表数量 - 挑 1–2 个典型表，运行
SHOW CREATE TABLE `t_user`;，看是否返回完整建表语句（注意反引号要保留） - 如果生产库是 RDS（如阿里云 RDS、腾讯云 TDSQL），检查控制台是否开启了「元数据访问权限」或「information_schema 可见性开关」
选对「源」和「目标」——顺序错了，同步方向就全反了
结构同步不是双向 diff 工具，它本质是「生成从源到目标的 DDL 变更脚本」。如果你把开发库设为「目标」、生产库设为「源」，Navicat 就会试图把生产库的结构“覆盖”到开发库——这跟你想找「开发比生产多了哪些字段」完全相反。
正确做法：
- 想看「开发库有哪些改动还没上生产」→ 开发库是
源，生产库是目标 - 同步时勾选
Compare only（仅比对），别急着点Run Synchronization - 比对结果里，左侧显示的是
源（开发库）的当前状态，右侧是目标（生产库）的当前状态；绿色加号表示源有、目标无（比如开发新加了is_deleted字段），红色减号表示源删了、目标还有（比如开发删了old_desc字段）
字段类型差异常被忽略：tinyint(1) 和 boolean 在 MySQL 里不是一回事
Navicat 默认按字符串精确匹配字段定义，TINYINT(1) 和 BOOLEAN 虽然底层都是 TINYINT，但 DDL 输出不同。如果开发库用了 BOOLEAN，生产库是 TINYINT(1)，结构同步会把它标为「不一致」，哪怕语义完全等价。
这类问题不会导致同步失败，但会干扰判断。应对方式：
- 在同步设置里打开
Options > Compare settings > Ignore tinyint(1) vs boolean（新版 Navicat 16+ 支持） - 如果没这个选项，导出比对报告后手动过滤掉这类条目，重点关注
type changed中涉及VARCHAR → TEXT、INT → BIGINT、NOT NULL ↔ NULL等真实风险项 - 注意
CHARACTER SET和COLLATE也要显式一致，否则即使字段名类型都一样，也会被标记为差异
同步前务必导出 SQL 脚本并人工审核，别信「一键」二字
Navicat 生成的同步 SQL 是自动拼的，对复杂变更容易出错。例如：给大表 ADD COLUMN 时没加 AFTER 位置，导致字段顺序错乱；或者把 MODIFY COLUMN 写成 CHANGE COLUMN 却漏掉旧字段名，直接报语法错误。
安全操作链：
- 点击
Save as SQL File...导出脚本，不要直接运行 - 用文本工具搜索
ALTER TABLE.*engine=，确认没有意外修改存储引擎（尤其不能把 InnoDB 改成 MyISAM） - 对含
DROP、RENAME、MODIFY的语句逐行核对：目标表是否存在？字段是否正被业务使用？有没有外键约束被连带影响？ - 生产环境执行前，在测试库回放一遍，用
SELECT * FROM t_xxx LIMIT 1验证字段可见性与顺序
最易被忽略的是字符集继承逻辑——如果库级 DEFAULT CHARSET=utf8mb4，但某张表建表时没显式声明，Navicat 同步可能按连接默认值补上 utf8，造成后续插入 emoji 失败。这种细节，只有看 SQL 才抓得住。
