Navicat导出SQL脚本失败主因是字符集不匹配，应设连接字符集为utf8mb4并勾选“导出为UTF-8编码”；导出粒度按需选择结构或数据；语句类型依场景选INSERT/REPLACE；需清理MySQL条件注释等头信息。
导出的SQL脚本打不开或报错，大概率是字符集没对上
navicat 默认用系统 locale 编码保存 sql 文件（windows 上常为 gbk），但 mysql 服务端、客户端默认走
。你双击用记事本打开看似正常，一导入就报
或乱码，根源在这儿。
实操建议：
导出前在 Navicat 连接设置里确认「高级」→「字符集」设为
（不是
）
导出时勾选「导出为 UTF-8 编码」（路径：导出向导 → 「格式」页 → 勾选该选项）
如果已导出且是 GBK 编码，别用记事本另存为 UTF-8——它会静默损坏 BOM 和多字节字符；改用 VS Code 或 Notepad++ 手动转码并保存为 UTF-8 无 BOM
导出结构+数据还是只导结构？看你是要迁移还是建新库
这个选择直接影响脚本体积、执行耗时和后续可维护性。很多人导完发现脚本几百 MB，根本没法用，就是误选了「导出结构和数据」还勾了「包含外键约束」+「插入所有行」。
实操建议：
仅部署新环境/初始化空库 → 选「仅导出表结构」，再单独用
对比验证
需要完整复制某张表（比如备份配置表）→ 在对象列表里只勾选那张表，导出时选「结构和数据」，并取消勾选「添加 DROP TABLE 语句」（避免误删）
导出整个库且含大量数据 → 改用命令行
，Navicat 导出大表容易卡死或内存溢出
“导出为 INSERT” vs “导出为 REPLACE”：主键冲突时行为完全不同
这个选项藏在导出向导「格式」页底部，默认是
。如果你导出后想直接覆盖目标库同名表的数据，
会因主键重复直接报错中断；而
是先删后插，等价于
，但会重置自增 ID 并触发
行为。
实操建议：
做数据同步或补漏 → 用
（需手动在导出后全局替换
为
）
确定目标表完全空或可清空 → 选
，但得提前确认外键约束是否启用（
必须写在脚本开头）
导出脚本用于版本管理（如 Git）→ 坚决不用
，它让 diff 失去意义，也掩盖真实变更
导出的 SQL 脚本执行失败，先检查这三行“隐形头信息”
Navicat 导出的 SQL 文件开头常带几行注释和设置语句，比如
、
。这些在 Navicat 里能跑，但粘贴到 phpMyAdmin 或某些 ORM 的 raw query 里会直接语法错误。
实操建议：
导入前用文本编辑器打开脚本，删掉所有以
开头的条件注释行（它们是 MySQL 特有语法，其他数据库不认）
检查是否有
—— 如果目标库名不同，必须手动改成实际库名，否则执行时提示
若脚本含存储过程或函数，Navicat 默认不导出其定义体（只导调用），需在导出设置里打开「导出存储过程/函数」开关，并确保连接用户有
权限
字符集、导出粒度、语句类型、头信息——这四个点没对齐，脚本基本等于废稿。尤其注意 Navicat 的「UTF-8 编码」选项默认不勾选，90% 的乱码问题都栽在这儿。
utf8mb4incorrect string valueutf8mb4utf8mysqldump --no-datamysqldumpINSERTINSERTREPLACEDELETE + INSERTON DELETEINSERT IGNOREINSERTINSERT IGNOREREPLACESET FOREIGN_KEY_CHECKS=0REPLACE/*!40101 SET NAMES utf8mb4 */;/*!40103 SET TIME_ZONE='+00:00' */;/*!USE `dbname`;Unknown databaseSELECT ROUTINE