Navicat逻辑模型导出物理模型前须检查三件事：一、确认DBMS设置与目标库完全一致（如MySQL 8.0而非MySQL）；二、手动补全主键字段的Auto Increment属性；三、检查ENUM/SET字段在目标库是否原生支持，否则改用VARCHAR+应用层校验。
Navicat 里逻辑模型导出物理模型前必须检查的三件事
逻辑模型转物理模型不是点一下“生成 sql”就完事——navicat 会按当前连接的数据库类型（mysql、postgresql、sql server 等）自动映射数据类型和约束，但映射结果往往和你预期不一致，尤其在主键策略、时间类型、枚举处理上容易出错。
实操建议：
- 确认当前模型的
DBMS设置与目标库完全一致：右键模型 → 编辑模型 → 检查DBMS下拉框选的是MySQL 8.0而不是MySQL（后者默认按 5.7 行为映射） - 手动补全所有
Primary Key字段的Auto Increment属性：Navicat 不会自动推断自增，漏设会导致生成的建表语句里没有AUTO_INCREMENT - 检查
ENUM或SET类型字段是否用了原生支持：MySQL 支持，但 PostgreSQL 会转成TEXT+CHECK，SQLite 直接报错；若目标库不支持，得提前改用VARCHAR+ 应用层校验
用“正向工程”生成物理模型时最常踩的坑
“正向工程”（Forward Engineering）是 Navicat 把逻辑模型落地为真实数据库结构的核心功能，但它默认跳过很多关键确认环节，导致生成的 SQL 在实际执行时报错或行为异常。
常见错误现象：ERROR 1067 (42000): Invalid default value for 'created_at'（MySQL 5.7+ 严格模式下 DATETIME 不能设 DEFAULT '0000-00-00 00:00:00'）
实操建议：
- 生成前务必点开
Options→ 勾选Generate DROP statements before CREATE：避免重复运行脚本时因表已存在而中断 - 在
SQL Generation页签下，把Default value for TIMESTAMP/DATETIME改成CURRENT_TIMESTAMP，而不是留空或填0000-00-00 00:00:00 - 禁用
Generate comments：Navicat 生成的注释语法（如-- Table comment）可能被某些旧版客户端截断，引发解析失败
生成的 SQL 脚本怎么安全导入到目标库
Navicat 导出的 SQL 是纯文本，但直接粘贴进查询窗口执行风险很高：缺少事务包裹、无错误中断机制、外键约束顺序错乱都可能导致半截建表。
使用场景：你有一套新库要初始化，或者测试环境需要频繁重置结构
实操建议：
- 不要用 Navicat 的
Execute Batch File功能直接跑大脚本：它不支持DELIMITER，遇到存储过程就会挂 - 改用命令行导入（更可控）：
mysql -h localhost -u root -p mydb ，注意文件编码必须是UTF8，否则中文注释变乱码 - 如果脚本含外键，确保先关掉外键检查：
SET FOREIGN_KEY_CHECKS = 0;开头，SET FOREIGN_KEY_CHECKS = 1;结尾——Navicat 默认不加这俩，但跨表依赖时必加
逻辑模型里画了关系线，为什么生成的物理模型没建外键
这是最让人困惑的一点：图上明明连了线，生成的 CREATE TABLE 里却只有字段，没有 FOREIGN KEY 定义。根本原因不是 Navicat 漏了，而是你没激活“引用完整性”开关。
参数差异：Navicat 区分「关系线」（仅可视化）和「引用关系」（带约束语义），后者必须手动启用
实操建议：
- 双击关系线 → 打开
Relationship Properties→ 在Referential Integrity标签页勾选Enforce Referential Integrity - 检查两端字段数据类型是否严格一致：比如一端是
BIGINT UNSIGNED，另一端是BIGINT，Navicat 会静默放弃建外键 - MySQL 中若引擎不是
InnoDB，外键会被忽略——生成前确认模型中每张表的Engine属性设为InnoDB
真正麻烦的不是步骤多，而是每个环节都有“默认不生效”的隐藏开关。漏一个，后面就得手动补 SQL，还容易和模型不同步。
