Navicat 里导入 SQL 文件，文件最快的导入路径是右键连接里的数据库，选“运行 SQL 文件”。文件但这一步之前有个坑：你得先建好目标数据库。导入很多人拿到一个 .sql 文件，文件直接双击打开，导入Navicat 弹出一堆乱码或者语法报错，文件就是导入因为没搞清楚这个文件是“建库建表插数据”一条龙的，还是文件只插数据。

我上周帮同事处理一个 200MB 的导入备份文件。他直接在 Navicat 里新建查询，文件把文件内容复制进去执行，导入结果卡了十分钟，文件软件直接崩了。导入正确做法是文件走“运行 SQL 文件”这个入口，它不会把内容加载到编辑器里，而是流式读取执行，内存占用小得多。

先确认你的 SQL 文件是什么类型

用文本编辑器打开文件头部看一眼。如果开头是 CREATE DATABASE 或者 USE xxx;，说明它自带建库语句。这种情况最简单：在 Navicat 里右键任意一个已有连接，选“运行 SQL 文件”，文件路径选好，然后注意下面有个“数据库”下拉框——别选具体库，留空或者选那个连接本身，让它自己按文件里的 CREATE DATABASE 去创建。执行完刷新一下连接，新库就出来了。

另一种情况是文件开头直接 CREATE TABLE，没有建库语句。你得先手动建一个空库。右键连接 → 新建数据库 → 字符集选 utf8mb4（除非你确定是老项目用 latin1），排序规则选 utf8mb4_general_ci 或 utf8mb4_unicode_ci 都行。建好之后，右键这个新库 → 运行 SQL 文件 → 选中文件 → 执行。

字符集和编码问题最烦人

导入完发现中文全是问号，或者报 Incorrect string value 错误。九成是编码对不上。Navicat 运行 SQL 文件那个窗口，右下角有个“编码”下拉框。默认可能是 Auto，但 Auto 经常猜错。你手动切成 UTF-8 或者 GBK 试试。判断方法：用记事本打开 SQL 文件，另存为的时候看默认编码是什么。Windows 上老文件很多是 ANSI（其实就是 GBK），Linux 导出的通常是 UTF-8。

还有个细节：Navicat 的“运行 SQL 文件”窗口里，编码选项控制的是读取这个 .sql 文件时的解码方式，跟数据库本身的字符集是两回事。数据库字符集在新建库的时候已经定了，改不了。所以如果库是 latin1，文件是 UTF-8，导入进去照样乱码。这种情况要么重建库，要么在 SQL 文件开头加 SET NAMES utf8mb4;。

大文件怎么处理

超过 500MB 的 SQL 文件，Navicat 直接导入容易超时。两个办法。一是用命令行：mysql -u root -p 数据库名 < 文件路径，比图形界面快得多。二是把大文件拆成几个小文件，按表拆或者按行数拆。我一般用 split 命令按行切，每 50 万行一个文件，然后逐个导入。

另外注意 Navicat 版本。16 之前的版本对大文件支持很差，导入 1GB 以上基本必崩。17 之后好了很多，但内存还是吃紧。如果机器只有 8GB 内存，建议还是走命令行。

导入完记得检查

别导完就关掉。随便点开几张表看看数据量对不对，中文显示是否正常。有个简单办法：在 Navicat 里右键数据库 → 数据字典 → 生成 HTML，能看到每张表的行数和字段信息。对比一下源文件里的 INSERT INTO 大概有多少条，心里有个数。

最后说个容易忽略的点：如果 SQL 文件里有 DROP TABLE IF EXISTS，导入会直接删掉同名表。生产环境操作前一定先备份。我见过有人把测试库的 SQL 导到正式库，把正式表全删了，就是因为没注意文件开头那几行。