在生产环境中，不建议直接使用「模型同步到数据库」功能，因为该操作会先 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出现异常
数据库上线后必须人工验证的三件事
Na vicat 显示的「运行成功」提示并不等于真正没有问题，很多数据库结构问题只有在真实业务查询中才会暴露出来：
- 第一时间执行
SHOW CREATE TABLE，确认字段顺序、默认值以及时间类型字段是否被自动补上了CURRENT_TIMESTAMP - 执行
SHOW INDEX FROM，检查索引是否存在冗余、是否遗漏创建，或者是否使用了错误的前缀长度 - 观察慢日志中的首批请求表现：字段类型隐式转换、索引失效、字符集不一致导致的排序异常，通常都会在这个阶段暴露
数据库模型应主要用于表结构设计和团队协作，而不应直接用于生产部署流程。所有生产环境中的数据库变更，都必须经过结构同步预览、SQL 审计、版本与字符集核对，以及上线后的即时验证这四个步骤。只有这样，才能更安全地完成生产数据库结构同步，降低数据丢失和兼容性风险。
