结构同步前须确认三件事：MySQL版本兼容性、目标库用户权限是否含ALTER/CREATE/DROP、目标库是否存在同名但已手动修改的表。
用 Navicat 结构同步前，先确认这三件事
结构同步不是点“开始”就完事的——它本质是生成并执行 ddl 脚本，一旦误操作，可能直接 drop table 或改错字段类型。所以动手前必须核对：
- 源库（测试库）和目标库（生产库）的 MySQL 版本是否兼容？比如在 5.7 上用的
JSON类型，同步到 5.6 会报错 - 目标库用户是否有
ALTER、CREATE、DROP权限？只给SELECT和INSERT是不够的 - 目标库中是否存在同名但结构已手动修改过的表？Navicat 默认按“差异部署”，不会跳过冲突表，也不会提示你“这个表上次被 DBA 手动加了索引”
Navicat 结构同步时，“对比→勾选→部署”三步里的关键控制点
很多人点完“部署”就等结果，但真正决定安全性的，是中间那个勾选环节。
- 点击“对比”后，Navicat 会列出所有差异项：新增字段、删除字段、类型变更、索引增删等。默认全选，但你要手动取消勾选：
DROP COLUMN、DROP INDEX、DROP TABLE—— 这些操作在生产环境上基本等于“自毁” - 如果只是想加个字段或索引，就只保留对应行的勾选；如果是改字段长度（如
VARCHAR(50) → VARCHAR(100)），可以保留；但改类型（如INT → BIGINT）要小心，某些旧版本 MySQL 会隐式锁表 - 点“部署”后别急着点“运行”，先看生成的 SQL 脚本——检查有没有
ALTER TABLE ... MODIFY或CHANGE带NOT NULL强制约束，这类语句在有空值数据时会失败
为什么不能跳过结构同步，直接用 mysqldump 导出再导入？
因为这是“重建”而非“同步”。它看似简单，实则破坏性极强：
-
mysqldump -d只导结构，但不包含视图、存储过程、触发器权限等元信息；若目标库已有同名对象，导入会报错或覆盖 - 用完整导出（含数据）再导入，等于把生产库整个清空重刷——所有线上正在写入的数据、自增 ID、主从位点都会丢失
- 如果只是想把测试库新加的字段/索引“合入”生产库，用 dump 就像为修一颗螺丝而拆掉整台发动机
上线前必做：用 SELECT 检查结构变更是否生效且无副作用
脚本跑完不代表万事大吉。有些变更表面成功，实际埋了雷：
- 执行
SHOW CREATE TABLE，确认新增字段位置、默认值、是否NOT NULL，尤其注意时间字段是否被自动加上了CURRENT_TIMESTAMP - 查一下索引：用
SHOW INDEX FROM，确认新索引没和现有索引重复（比如已有(a,b)，又加了个(a)，属于冗余） - 如果表上有应用正在读写，观察慢查询日志里是否突然出现
ALTER TABLE相关的锁等待；MySQL 5.6+ 支持ALGORITHM=INPLACE，但 Navicat 不一定默认启用，得看生成脚本里有没有显式指定
结构同步最危险的时刻，不是执行那一刻，而是你没看清“对比结果”就点了全选。生产库没有后悔键，每一条 DDL 都该当作一次手术来准备。
