结构同步是唯一可靠路径：Navicat仅支持已连接数据库间的结构同步比对，不接受SQL文件；需确保连接有效、权限充足、字符集一致；源/目标方向不可颠倒；差异基于解析后的对象模型而非文本，DDL预览和脚本审查必不可少。
结构同步是唯一可靠路径
navicat 没有“直接比库”的按钮，所谓对比，本质是结构同步流程中的一环。你点的不是“对比”，而是“结构同步→比对”，它只在两个**已连接且可访问的数据库**之间工作，不接受备份文件、dump 输出或离线 sql 脚本。
常见错误是试图把 mysqldump 导出的 test.sql 和 staging.sql 文件拖进 Navicat 点“比对”——这根本不会触发任何逻辑，界面也不会响应。
- 确保测试库（如
test_db）和预发布库（如staging_db）都已在 Navicat 中建立有效连接，且账号有SELECT和SHOW VIEW权限 - 两个库必须使用相同字符集（重点检查
utf8mb4vsutf8），否则字段名或注释可能被误判为差异 - 若库名不同但结构意图一致（比如
app_test和app_staging），无需重命名，Navicat 比对的是对象定义，不是库名本身
执行结构同步前必须确认目标方向
Navicat 的“源”和“目标”不是对称的：它生成的变更脚本，永远是从源库结构调整为目标库结构。也就是说，如果你选错方向，生成的 SQL 会把预发布库改成测试库的样子，而不是反过来。
典型场景是：你想让预发布库跟测试库保持一致 → 那么源必须是 test_db，目标必须是 staging_db。点“比对”后看到的“缺失表”“字段多余”等提示，都是站在 staging_db 角度说的：“你缺了这个，你多了那个”。
- 右键连接 → “结构同步”，不要从工具栏盲点；菜单里没有“数据库对比”独立入口
- 源/目标选反了？别急着点“部署”，先看下方 DDL 预览区：如果看到
DROP TABLE或大量ALTER TABLE ... DROP COLUMN，大概率方向错了 - 点击某个表名，在下方面板能看到左侧（源）和右侧（目标）各自的完整 DDL，这是验证语义是否真不同的最准方式
DDL 比较选项卡显示的是解析后结果，不是原始 SQL
你看到的差异不是文本 diff，而是 Navicat 把两个库的表结构分别解析成内存对象模型后，再逐字段、索引、约束比对的结果。所以同一逻辑的写法（比如 INT NOT NULL vs INT(11) NOT NULL）会被视为等价，而换行缩进、注释、空格全被忽略。
这也意味着：如果你在测试库手动加了 ON UPDATE CURRENT_TIMESTAMP，但在预发布库漏写了，Navicat 会明确标出这一项差异；但如果你只是改了 SQL 文件里的注释位置，它完全不关心。
- 留意
DEFAULT值是否显式声明：MySQL 8.0+ 默认值隐式行为变化大，Navicat 会严格比对显式DEFAULT '2024-01-01'和无声明之间的区别 - 主键顺序、字段顺序变更也会被识别为差异，即使语义没变；某些 ORM 生成的建表语句字段顺序不稳定，容易引发误报
- 视图、存储过程、函数默认不参与比对，需在结构同步对话框里手动勾选对应类型才纳入
部署前务必审查生成的 SQL，尤其注意跨库语句
Navicat 生成的同步脚本默认不含 USE xxx 或 CREATE DATABASE，但它可能包含 ALTER TABLE `db_name`.`table_name` 这种带库名的全限定写法——如果目标库名和脚本里写的不一致，执行会失败。
更隐蔽的问题是：如果你的测试库用了 ENGINE=InnoDB ROW_FORMAT=DYNAMIC，而预发布库 MySQL 版本较低不支持该参数，Navicat 不会自动降级兼容，生成的脚本直接执行会报错。
- 点击“部署”后弹出的 SQL 预览窗口，逐条扫一遍：有没有
DROP DATABASE、RENAME TABLE这类高危操作？如有，说明源/目标设反或对象命名冲突 - 检查所有
ALTER TABLE是否都指向目标库内的表名，避免出现ALTER TABLE `test_db`.`users`这种无法执行的语句 - 生成脚本后，建议复制出来，在预发布库的查询窗口里先用
EXPLAIN FORMAT=TREE或简单SELECT 1测试语法合法性，再正式运行
DEFAULT，或者一个被忽略的 COLLATE。这些不会出现在文本 diff 里，但 Navicat 会揪出来——前提是，你得让它连上真实的库。 
