Navicat的正向工程不能直接建表，仅生成SQL脚本；需手动执行，且必须正确配置目标DBMS类型、关闭数据库名引用、检查语法兼容性，并人工处理注释、索引及字符集等上下文问题。
正向工程在Navicat里到底能不能直接建表
不能——navicat 的「正向工程」功能（forward engineering）本质是生成 sql 脚本，不是一键执行建表。它不自动连接数据库并执行 ddl，你得手动复制、粘贴、运行生成的语句，否则模型永远只是画布上的图形。
怎么从模型生成可用的建表 SQL
关键在导出前的配置：默认生成的 SQL 可能含 CREATE DATABASE、USE 或带引号的标识符（如 `user`），而你的目标库可能已存在、权限受限，或用的是 PostgreSQL/SQL Server 等不兼容 MySQL 引号语法的数据库。
- 右键模型 → “正向工程” → 勾选
Generate CREATE statements，取消勾选Generate DROP statements（除非真要删旧表） - 在
Target DBMS下拉菜单中，必须选对目标数据库类型（比如你连的是 PostgreSQL，就选PostgreSQL 12+，不能选默认的 MySQL） - 点击
Next后，在 “Options” 页面关掉Include database name in object names，避免生成类似mydb.users这种跨库引用（多数生产环境不允许） - 生成预览页里，务必检查
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4这类 MySQL 特有子句——如果目标是 SQL Server，它们就是非法语法
生成的 SQL 执行不了？常见报错和对应解法
最常卡在三类错误：ERROR 1064 (42000)（语法错）、ERROR 1050 (42S01)（表已存在）、ERROR 1215 (HY000)（外键约束失败）。根本原因不是模型画错了，而是正向工程没考虑执行上下文。
-
ERROR 1064：多半因目标 DBMS 类型选错，比如用 MySQL 模式生成语句去跑 PostgreSQL；或模型里用了 Navicat 不识别的字段类型（如JSON在旧版 MySQL 模式下会转成TEXT，但加了JSON_VALID()检查就挂了） -
ERROR 1050：正向工程默认不加IF NOT EXISTS，脚本重复执行必报错；手动在CREATE TABLE前补上（MySQL 8.0+ / PostgreSQL 9.6+ 支持，SQL Server 用IF NOT EXISTS (SELECT * FROM sys.tables WHERE name = 'xxx')） -
ERROR 1215：外键引用的表还没建，或字段类型不严格一致（比如主表是INT UNSIGNED，从表是INT就不认）；生成后按建表顺序手动调整 SQL 执行顺序，或拆成两步：先建所有表，再批量加外键
为什么别依赖 Navicat 自动生成的注释和索引
Navicat 从模型导出的 COMMENT 会硬编码进字段定义（如 name VARCHAR(50) COMMENT '用户名'），但 PostgreSQL 不支持字段级 COMMENT 写在 CREATE 里，得用独立 COMMENT ON COLUMN 语句；索引也一样——它把 INDEX idx_name ON users(name) 直接塞进 CREATE TABLE，可有些场景你需要延迟创建索引（比如大数据量导入后再建），或者想指定表空间、并发选项。
- 模型里的字段注释，建议导出后统一用脚本二次处理：MySQL 用
ALTER TABLE ... COMMENT，PG 用COMMENT ON COLUMN - 索引不要放在建表语句里，单独提取出来，用
CREATE INDEX CONCURRENTLY（PG）或CREATE INDEX ... ONLINE=ON（SQL Server）提升上线安全性 - 如果模型里用了复合主键或唯一约束，Navicat 生成的约束名像
PRIMARY_1这种，上线后排查问题极难定位；导出后手动重命名为pk_users_id级别
模型和数据库之间永远隔着一层人工校验——生成 SQL 只是起点，不是终点。最容易被忽略的是字符集继承逻辑：模型设了 utf8mb4，但目标库默认字符集是 latin1，建出来的表还是乱码，这得提前改库级配置，不是改 SQL 能解决的。
