navicat的sql预览仅实时显示gui操作生成的ddl语句（如create/alter table），不执行、不校验、不反映真实数据库解析结果，且省略默认值、不提示外键名截断等隐患，需通过“转储sql文件”导出后走查。
navicat 里 sql 预览到底显示什么？
Navicat 的「SQL 预览」（右键表 →「设计表」→ 切换到「SQL」标签页，或执行 DDL 操作前弹出的预览窗口）只展示 Navicat 自动生成的 DDL 语句，不运行、不校验、不模拟执行计划。它本质是 GUI 操作的“翻译结果”，不是 MySQL 或 PostgreSQL 真实解析后的语句。
- 它可能省略默认值（如
ENGINE=InnoDB在 MySQL 8.0+ 中常被隐藏） - 字段顺序与你在「设计表」界面拖拽的顺序一致，但真实建表时顺序不影响功能
- 不会反映你手动写的触发器、外键约束名（如果用的是老版本 Navicat），除非你显式勾选了「导出外键」选项
所以靠它做走查，第一件事是确认：你看到的，就是团队最终要上线的 DDL 吗？大概率不是——得导出、清洗、再比对。
怎么把预览 SQL 变成可走查的代码？
Navicat 自带的「复制为 SQL」和「导出为 SQL 文件」功能，输出质量差异很大：
-
复制为 SQL：只复制当前表结构，不含CREATE DATABASE、USE、字符集声明，也不加事务包装 -
导出为 SQL 文件（右键数据库 →「转储 SQL 文件」→「结构」）：可选「兼容模式」「添加 DROP 语句」「导出外键/注释」，这才是走查可用的源
建议走查前统一执行以下操作：
- 用「转储 SQL 文件」导出，勾选「兼容模式：MySQL 5.7」（即使线上是 8.0，也避免
JSON类型或隐式默认值引发歧义） - 手动在导出文件开头加上
SET FOREIGN_KEY_CHECKS = 0;和SET SQL_MODE = 'STRICT_TRANS_TABLES'; - 删掉所有
-- Host: ...、-- Date: ...这类无意义注释，保留业务相关注释（如字段用途） - 用
mysql --no-defaults -e "source /path/to/file.sql"在本地测试库快速验证语法是否通过（不真正建表，只 parse）
走查时重点盯哪些 Navicat 不会提示的问题？
Navicat 的 SQL 预览不会警告这些高频隐患：
-
TEXT字段没设CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs，导致 emoji 存储异常 -
TIMESTAMP字段默认值写成CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，但在 MySQL 5.6 下不支持多CURRENT_TIMESTAMP列 - 外键名过长（超过 64 字符），Navicat 会自动截断并静默重命名，但迁移工具（如 Flyway）可能报错
-
ENUM值含单引号但未转义，导出后变成ENUM('a''b', 'c')，实际应为ENUM('a''''b', 'c')
最稳妥的做法：把导出的 SQL 拷进 VS Code，装好 SQLTools 插件，连上同版本目标库，用「Execute Current Statement」逐条试跑——不是看结果，是看错误信息是否和预期一致。
多人协作时怎么避免 Navicat 预览造成理解偏差？
不同人用的 Navicat 版本、语言包、区域设置不同，会导致预览输出不一致：
- 英文版 Navicat 16 导出的
datetime默认带NOT NULL，中文版可能不写（依赖 GUI 是否勾选「允许空值」） - macOS 上 Navicat 对反引号
`的处理比 Windows 更激进，字段名带空格时可能多套一层
所以团队必须约定：
- DDL 走查只认「转储 SQL 文件」导出的内容，禁用「SQL 预览」窗口直接截图或复制
- 所有 DDL 提交 Git 前，用
mysqldump --no-data --skip-triggers --skip-routines [db] [table]生成基准语句，和 Navicat 导出做diff - 在 PR 描述里明确写清：「此 SQL 经 Navicat 16.1.12（macOS）导出，已用 MySQL 8.0.33 实例验证 CREATE 语法」
Navicat 的 SQL 预览是个便利入口，不是权威信源。真正卡住上线的，往往就藏在它默认折叠的那几行字符集、排序规则和 SQL mode 设置里。
