结构同步前须确认源（开发库）与目标（测试库）连接均真实可用，手动执行INFORMATION_SCHEMA查询和SHOW CREATE TABLE验证元数据可读性，避免因连接不可靠或权限不足导致静默跳过表或报Access denied；源目标顺序不可颠倒，绿色加号表示开发有而目标无，红色减号表示开发删而目标仍有，需逐条核对并导出SQL人工审查后再执行。
结构同步前，先确认两个连接都真正“活”着
很多“比对失败”根本不是功能问题，而是连接本身不可靠。navicat 的结构同步依赖完整读取 information_schema 和执行 show create table，如果开发库连接看似在线、实则权限受限或网络抖动，比对会静默跳过部分表，甚至报 access denied for user。
实操建议：
- 在两个连接上分别手动执行
SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'your_db_name';，确认返回数量一致 - 挑 1–2 个典型表（如
t_user），运行SHOW CREATE TABLE `t_user`;，看是否返回完整建表语句（注意反引号不能丢） - 若开发库是本地 Docker 实例或低配云数据库，检查是否禁用了
INFORMATION_SCHEMA查询（某些轻量版 MySQL 镜像默认关闭）
源库必须是开发库，目标库必须是待修复的“脏”环境
结构同步不是双向 diff 工具，它只生成「从源到目标」的 DDL 变更脚本。如果你把测试库设为源、开发库设为目标，Navicat 就会试图把测试库结构覆盖回开发库——这跟你想“把开发最新结构推过去”完全相反。
正确做法：
- 想修复测试库缺失字段 → 开发库是源，测试库是目标
- 右面板标着“目标”的连接名必须带明确环境标识，比如
TEST_MySQL_OrderDB，别用模糊名如order_db - 连接属性里给目标库设红色标签（外观 → 颜色），视觉上形成强警示
比对结果里绿色加号和红色减号，要逐条人工核对
左侧（源）显示开发库当前状态，右侧（目标）显示待修复环境当前状态。绿色加号表示开发有、目标无（如新增了 is_deleted 字段），红色减号表示开发删了、目标还有（如开发删了 old_desc 字段）。
容易踩的坑：
-
TINYINT(1)和BOOLEAN被标为不一致：MySQL 底层等价，但 DDL 输出不同。新版 Navicat 17 支持在Options > Compare settings中勾选Ignore tinyint(1) vs boolean；旧版需手动过滤 - 字段顺序不同被误判为「删+增」：在
Options页勾选Ignore column order - 黄色警告提示「可能截断」：如开发是
VARCHAR(200)，目标是VARCHAR(50)，必须先查目标数据实际最大长度：SELECT MAX(CHAR_LENGTH(column_name)) FROM table_name;，再决定是否扩宽
别点「Run Synchronization」，先导出 SQL 并逐行检查
Navicat 生成的脚本默认不含事务，也不做数据校验。直接执行等于把风险全交给数据库引擎扛。
关键检查点：
- 是否有
DROP COLUMN或DROP TABLE？这类操作必须确认目标环境确实不需要该字段/表 - 是否有
ADD COLUMN xxx NOT NULL？必须补默认值，否则线上执行失败（如改成ADD COLUMN xxx VARCHAR(32) DEFAULT ''） - 大表（>100 万行）的
ADD COLUMN建议拆分：先加带默认值的列，再用后台任务分批更新 - 字符集和排序规则是否显式声明？比如
VARCHAR(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs，避免继承库级默认导致 join 异常
最常被忽略的是外键依赖：如果目标表被其他表引用，DROP COLUMN 会直接失败。预览 SQL 时务必确认是否已勾选 Disable foreign key checks，且你清楚后果。
