导出 SQL 前必须确认模型已保存且 Database Type 与 Version 匹配目标环境，否则类型不兼容（如 JSON→TEXT）、语法被忽略（如 generated always）、排序规则报错（如 utf8mb4_0900_ai_ci）等。
导出前必须确认模型已保存且目标数据库类型匹配
navicat data modeler 的「导出 sql」功能不会校验模型是否与目标数据库兼容，比如你在关系型建模模式下设计了分区表或 json 字段，但选了 mysql 5.6 版本导出，json 类型就会变成 text，且不报错。务必在导出前点开模型右上角的 model properties，核对 database type 和 version 是否与你实际要部署的环境一致。
- MySQL 模型不能直接导出为 SQL Server 脚本，反之亦然
- 维度建模（Star Schema）导出时默认不生成
FOREIGN KEY约束，需手动勾选「Generate foreign keys」 - 如果模型里用了自定义数据类型（如
ENUM('active','inactive')），导出时可能被简化为VARCHAR(20)，取决于目标版本支持情况
点击「导出 SQL」后关键参数不能跳过高级设置
从模型窗口点击 Tools → Export SQL 打开导出对话框，直接点「确定」会用默认配置生成脚本，但默认配置往往漏掉关键项。必须点开 Advanced 面板手动调整：
-
Server Version下拉框要精确到小版本（如选MySQL 8.0.33而非MySQL 8.0），否则generated always as表达式可能被忽略 - 勾选
Drop tables before creation仅在测试环境安全；生产环境误选会导致DROP TABLE语句被写入脚本 -
Export comments建议开启，否则模型中添加的字段注释（COLUMN_COMMENT）不会出现在COMMENT子句里 - 若模型含视图或存储过程，需单独勾选
Export views或Export routines，它们默认不参与导出
导出的 SQL 脚本不执行？先检查字符集和引擎声明
Navicat 生成的脚本默认带 CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci 这类声明，但如果你导出目标是 MySQL 5.7 或更低版本，该排序规则不被识别，执行会报错 Unknown collation: 'utf8mb4_0900_ai_ci'。类似地，ENGINE=InnoDB ROW_FORMAT=DYNAMIC 在旧版本也可能失败。
- 解决办法：导出后用文本编辑器全局替换
utf8mb4_0900_ai_ci为utf8mb4_general_ci - 若目标库禁用
innodb_file_per_table，删掉脚本中所有ROW_FORMAT字段声明更稳妥 - 注意脚本开头是否有
SET NAMES utf8mb4;—— 如果目标连接未设该编码，中文注释可能乱码
逆向工程来的模型导出时容易丢索引和外键
用 Navicat 的「Reverse Engineer」从现有库加载成模型后，再导出 SQL，常发现 UNIQUE KEY 或 FOREIGN KEY 没出现在脚本里。这不是 Bug，而是因为逆向过程中部分约束未被解析为模型对象——尤其当原库使用了前缀索引（INDEX idx_name (col1(10))）或外键未启用 ON UPDATE CASCADE 等显式动作时，Navicat 默认不将其转为可导出的模型元素。
- 验证方式：在模型画布中双击某张表，看
Indexes和Relations标签页是否为空 - 补救操作：手动在模型中右键表 →
Edit Table → Indexes重新添加缺失索引 - 外键必须通过拖拽关系线建立（而非仅靠字段名匹配），否则导出时不会生成
CONSTRAINT语句
Auto Increment 属性在逆向后丢失，导出时就变成普通 INT。动手前多花三十秒点开属性面板扫一眼，比导出后调试半天强。
