「模型同步到数据库」不可用于生产环境，因其会暴力 drop 再 create 表，清空数据、忽略字段差异、不校验外键与版本兼容性；应改用「结构同步」并严格执行预览、审计、核对、验证四步流程。
不能直接用「模型同步到数据库」推生产环境——它会 drop 再 create 表，不保留数据、不校验字段差异、不检查外键依赖。
为什么「模型同步到数据库」按钮是危险操作
这个功能本质是把模型导出为完整 CREATE TABLE 脚本，然后在目标库上暴力执行。它不会读取现有表结构，也不做任何增量判断：
- 哪怕你只改了
DEFAULT值，它也会先DROP TABLE，再CREATE TABLE，整张表数据清空 - 模型里没设主键，但生产表已有主键？同步后主键被删，后续
INSERT可能违反唯一约束 - 模型设为
MySQL 8.0，连接的是5.7实例？生成的JSON字段或GENERATED COLUMN语法直接报错 - 日志只显示“成功/失败”，不输出实际执行的 SQL，无法审计或回滚
真正可用的路径：用「结构同步」代替「模型同步」
「结构同步」（工具 → 结构同步）才是面向生产环境的可控方式，它基于两个物理数据库做双向比对，而非单向覆盖：
- 必须手动确认源库（如测试库）和目标库（如生产库）的 MySQL 版本兼容性，比如
GENERATED COLUMN在5.7不可用 - 对比后默认勾选全部变更项，但你要主动取消：
DROP COLUMN、DROP INDEX、DROP TABLE—— 这些在生产上基本等同于事故 - 点击「部署」后务必点开生成的 SQL 脚本，检查是否有
MODIFY COLUMN NOT NULL这类语句；如果对应列存在空值，执行必然失败 - 字符集必须显式声明：新增字段若没写
CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs，会继承库级默认值，而那个默认值可能和旧列不一致，导致JOIN或ORDER BY出错
上线后必须人工验证的三件事
Navicat 的「运行成功」提示不可信，很多问题只在真实查询中暴露：
- 立刻执行
SHOW CREATE TABLE，确认字段顺序、默认值、时间类型是否自动补了CURRENT_TIMESTAMP - 执行
SHOW INDEX FROM，检查索引是否冗余、是否漏建、是否用了错误的前缀长度 - 查慢日志第一波请求：字段类型隐式转换、索引失效、字符集不一致引发的排序异常，往往这时候才浮现
模型只该用于设计和协作，不是部署管道。所有生产变更必须经过结构同步预览、SQL 审计、版本与字符集核对、上线后即时验证这四步，缺一不可。
