Navicat 17结构同步是单向DDL变更而非恢复操作，需确保源库结构可信；同步前须校验字段现状、字符集、外键等隐性约束，并通过Preview SQL分步执行ADD COLUMN等高危操作。
Navicat 17 结构同步前必须确认源与目标是否可逆
结构同步不是“恢复操作”，而是单向比对+执行 ddl 变更。如果你误删了字段，但源数据库（比如备份库、测试库或 git 管理的 sql 脚本）仍保留该字段定义，才能用它找回；若源和目标都是同一个已损坏的生产库，同步只会把缺失字段“正式删除”得更彻底。
实操建议：
- 先用
SELECT * FROM information_schema.COLUMNS WHERE TABLE_NAME = 'your_table'在目标库查字段现状，确认哪些字段真丢了 - 找一个可信的“结构正确”的源：本地开发库、Git 提交记录里的
CREATE TABLE语句、上周的备份库（不是数据备份，是结构一致的完整库实例） - 在 Navicat 中右键点击源库 →
Structure Synchronization，**务必勾选Compare only structure (ignore data)**，否则可能触发意外的数据覆盖
字段丢失后同步时常见错误：Navicat 默认不还原 DROP COLUMN
Navicat 17 的结构同步默认策略是“使目标匹配源”，但它对已删除字段的处理取决于比对逻辑——如果源里有 name VARCHAR(50)，目标里没有，它会生成 ADD COLUMN name VARCHAR(50)；但如果源里字段类型/长度变了（比如从 VARCHAR(50) 改成 VARCHAR(100)），它可能生成 MODIFY COLUMN 或 CHANGE COLUMN，而不会回退到旧定义。
容易踩的坑：
- 没注意字段顺序：Navicat 默认按字母序排列字段，但 MySQL 实际建表顺序影响
INSERT ... VALUES的位置绑定，同步后建议手动检查SHOW CREATE TABLE输出 - 忽略
NOT NULL和默认值差异：若源字段是status TINYINT NOT NULL DEFAULT 0，目标是status TINYINT，同步会加NOT NULL DEFAULT 0，但若目标已有非空数据且该字段为 NULL，执行会失败，报错ERROR 1138: Invalid use of NULL value - 外键约束名冲突：如果目标库存在同名但定义不同的外键，同步可能跳过或报错
Cannot delete or update a parent row，需提前用SELECT CONSTRAINT_NAME, TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'db_name' AND REFERENCED_TABLE_NAME IS NOT NULL核查
如何让 ADD COLUMN 操作更安全：手动预检 + 分步执行
Navicat 同步窗口底部的 Preview SQL 按钮不是摆设。点击后你会看到它准备执行的全部 DDL，包括 ALTER TABLE ... ADD COLUMN。这时候别急着点 Run，先复制 SQL 到查询窗口手动跑一遍 EXPLAIN FORMAT=TREE ALTER TABLE ...（MySQL 8.0+）或查 INFORMATION_SCHEMA.INNODB_METRICS 看锁等待风险。
更稳妥的做法：
- 把
Preview SQL里的每条ADD COLUMN单独复制出来，在目标库执行前加SELECT COUNT(*) FROM your_table WHERE new_column IS NULL;验证字段是否真为空（避免误判） - 对大表（>100 万行），改用
ALGORITHM=INSTANT（MySQL 8.0.12+）：例如ALTER TABLE users ADD COLUMN avatar_url VARCHAR(255) ALGORITHM=INSTANT;，否则 Navicat 默认可能用 COPY 算法，导致锁表 - 如果字段带
DEFAULT值，MySQL 5.7+ 会自动填充历史行，但 Navicat 同步不会显式声明ALGORITHM，所以务必在预览 SQL 中补上，否则可能触发全表拷贝
同步完成后字段仍不可用？重点检查字符集和排序规则
字段出现在 DESCRIBE table 里，但应用写入时报 Incorrect string value 或查询结果乱码，大概率是字符集不一致。Navicat 同步只比对列定义，不校验表级/列级 CHARACTER SET 和 COLLATION。
快速验证方式：
- 对比源和目标的字段定义：执行
SHOW FULL COLUMNS FROM your_table LIKE 'column_name';，看Collation列是否一致（如utf8mb4_0900_ai_civsutf8mb4_general_ci） - 若不一致，不要依赖同步工具修复，直接在目标库执行：
ALTER TABLE your_table MODIFY COLUMN column_name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; - 特别注意 JSON 类型字段：MySQL 5.7+ 的
JSON列强制使用utf8mb4字符集，但 Navicat 同步可能忽略这点，导致后续JSON_VALID()返回 FALSE
真正麻烦的不是同步动作本身，而是你无法靠一次点击就确认所有隐性约束都对齐——字符集、SQL mode、generated column 的表达式、甚至用户自定义函数是否存在，这些 Navicat 都不会提醒。
