sql文件导入数据库

昨天下午，导据库隔壁工位的入数同事又把一个生产库的表结构导崩了。原因很简单——他拿到一个 .sql 文件，导据库二话不说就双击，入数用 Navicat 的导据库“运行 SQL 文件”功能直接灌。结果呢，入数文件开头几个 CREATE TABLE 语句里带着 IF NOT EXISTS，导据库后面却跟着一堆无脑 INSERT，入数主键冲突直接让整个导入过程卡死在中间，导据库半个库的入数数据处于半新半旧的状态。

这种场景我见过太多次了。导据库sql 文件导入数据库，入数说穿了就三件事：看明白文件内容、导据库选对导入工具、入数处理掉潜在冲突。导据库但绝大多数人连第一件事都不做。

拿到一个 .sql 文件，先别急着点导入。用文本编辑器打开它，哪怕只是扫一眼头部 50 行。你在找什么？找 CREATE DATABASE 和 USE 语句。很多从服务器上导出的文件自带这两行，意味着它要创建库或者切换库。如果你本机已经有同名库，且数据比这个文件里的还新，那这个文件一旦执行，你本机的数据就被覆盖了——不是合并，是覆盖。别问我怎么知道的，我去年就亲手干过这事，把客户一个月的测试数据全冲没了。

文件里如果没有 USE 语句，那导入前你得手动确认当前连接的数据库是哪个。这不是废话。我见过有人把本该导入 test 库的文件，导进了 dev 库，结果 dev 库的表结构和数据全乱了，代码跑起来各种报错，查了半天才发现是库选错了。

工具选择上，命令行永远是底线方案。mysql -u root -p database_name < file.sql 这条命令，简单直接，不跟你玩花活。它不会像某些图形工具那样，在导入中途弹个“是否继续”的对话框，然后你手一抖点了取消，留下一个半截的导入结果。命令行要么全成功，要么报错停住，错误信息也直白，哪一行出了问题清清楚楚。

图形工具方便是方便，但有个坑——默认的“遇到错误继续执行”选项。Navicat 和 DBeaver 都有这个设置，一旦开启，文件中间某条 INSERT 因为字段长度超限失败了，工具不会停，它会跳过这条，继续往下跑。等你看到“导入完成”的绿色提示，以为万事大吉，其实数据已经缺了一角。这种错误最阴险，因为它不报错，你得事后用 SELECT COUNT(*) 去核对行数才能发现。

再说说编码问题。UTF-8 的文件导进 GBK 的库，中文全变问号；反过来，GBK 的文件导进 UTF-8 的库，直接报错“Incorrect string value”。这个没法靠工具自动识别，你得在导入前确认两边编码一致。有个土办法：用记事本打开 sql 文件，另存为时看右下角编码显示，如果是 UTF-8，那导入时连接参数里也得写 UTF-8。别信什么“自动检测”，自动检测在中文环境下就是个笑话。

最后说个大文件。超过 500MB 的 sql 文件，别想着用图形工具一把梭。不是不行，是容易卡死，而且中途断了没法续传。正确做法是分段导入——用命令行配合 sed 或 split 把文件拆成小块，每块几百 MB，逐个执行。麻烦是麻烦点，但至少每块执行完你能确认成功，真出问题了也知道是哪一段出的。

导入完别急着走。花两分钟跑几个验证查询：查一下关键表的行数，对比源库；随机抽几条数据看看字段值是否完整；如果有自增主键，看看最大值是否合理。这比事后发现数据不对再回头排查高效得多。

sql 文件导入从来不是“双击运行”这么简单的事。它是个需要你动脑子的操作，先看、再选、后查，三步缺一不可。省这几分钟，后面可能得花几小时去补数据。你自己掂量。