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