把sql文件拖进命令行窗口，脚据库敲一行回车，本导看着屏幕滚过去几百行绿色提示符，入数数据库里就多了几张表。脚据库这事儿看起来简单，本导但我在工位上见过太多人卡在这一步——不是入数不会敲命令，而是脚据库连文件路径都写不对。

最常见的本导场景是这样：你从同事那里收到一个`init.sql`，或者从网上扒了个开源项目的入数建表脚本。双击打开，脚据库满屏的本导CREATE TABLE和INSERT INTO，没头没尾。入数这时候别急着双击运行，脚据库先干一件事——用记事本或VS Code打开文件，本导看一眼头部有没有`USE database_name;`这行字。入数没有的话，你导入的时候就得自己指定库，不然数据全灌进当前默认库，追都追不回来。

命令行导入是最原始也最不容易出错的方式。以MySQL为例，打开终端，先登录：`mysql -u root -p`，输密码进去后，先建库（如果脚本里没带）——`CREATE DATABASE IF NOT EXISTS mydb DEFAULT CHARSET utf8mb4;`，然后`USE mydb;`，最后一行搞定：`source /完整/路径/你的文件.sql;`。注意这里的路径分隔符，Windows下反斜杠可能被转义，建议直接正斜杠或者把文件拖进终端窗口，让系统帮你生成路径。

但有个坑你必须知道——如果脚本里有中文注释或者中文字符数据，而你的终端字符集是latin1，导入后你会看到一堆乱码。解决办法是在登录时加参数：`mysql -u root -p --default-character-set=utf8mb4`。这个细节坑了我一个下午，当时导完数据发现所有中文都变成了问号，差点把键盘砸了。

如果你不想碰命令行，图形工具更直观。Navicat或者DBeaver里，右键目标数据库，选“运行SQL文件”，弹出窗口选文件，点开始就行。但这里有个反直觉的地方——工具默认不会切换数据库，你得在弹窗顶部确认当前连接的库是不是你要导入的那个。我见过有人连着生产库的备份，却把测试环境的脚本导进去，结果表结构冲突，业务直接报错半小时。

PostgreSQL的玩法不太一样。命令行用的是`psql -U username -d dbname -f /path/to/file.sql`，注意`-d`参数指定数据库，没有的话会默认连到和用户名同名的库，大概率报错“数据库不存在”。SQL Server那边更折腾，用`sqlcmd -S server -U sa -P password -d dbname -i file.sql`，但SQL Server的脚本经常带`GO`批次分隔符，你要是用其他工具执行，可能卡在语法错误上。

导入失败最烦人的不是报错本身，而是报错信息不完整。MySQL默认一遇到错误就停，但有些脚本中间夹着几条坏数据（比如重复主键），你看到第100行报错，前面的99行其实已经执行了。再跑一遍又会因为表已存在而二次报错。我的习惯是导入前先看一眼脚本里有没有`DROP TABLE IF EXISTS`，没有的话自己手动先清一遍库，或者用`--force`参数跳过错误——但用了这个参数，你得自己回头检查哪些行没进去。

还有个土办法，适合几百行的小脚本——直接复制粘贴到数据库管理工具的命令行输入框里执行。但千万别这么干大文件，超过1MB的脚本粘贴过去会卡死编辑器，而且中间如果有个特殊字符被输入法吃掉，排查起来要命。

最后说个真事。上周帮同事排查问题，他导了一个30MB的备份文件，等了十分钟还没结束，以为卡死了就强制关闭。我一看，他用的Navicat，默认每1000条提交一次事务，30MB的数据量得跑很久。后来改用命令行导入，两分钟完事。工具是好工具，但大文件导入，命令行永远是最稳的。