把数据库导入这件事说清楚，导入其实比很多人想的数据要简单。上周帮同事处理一个本地开发环境，导入他拿到一份 2.3GB 的数据 MySQL 备份文件，双击打开是导入乱码，问我是数据不是文件坏了。不是导入坏了，是数据打开方式不对——那是个用 mysqldump 导出的 SQL 文本，得用命令行或客户端工具喂给数据库，导入用文本编辑器看当然满屏二进制乱码。数据

导入数据库的导入核心操作只有一句话：把数据从文件搬到数据库里。但“文件”和“数据库”这两个词各自能变出十几种花样，数据所以实际操作时容易卡住。导入下面按最常见的数据几种场景来说。

MySQL：命令行最稳

如果你手头是导入 .sql 文件，在终端里敲：

mysql -u root -p 你的数据库名 < /path/to/backup.sql

回车后输入密码，等它跑完就行。注意箭头方向，是文件流向数据库，别写反。这个命令不挑文件大小，2GB 也好 20GB 也好，它一行行读，内存占用很低。我见过有人用 Navicat 的图形界面导入大文件，进度条卡在 80% 半小时不动，换成命令行十分钟结束——图形工具在导入时往往会把整个文件先读进内存，大文件直接拖垮客户端。

如果文件是 .sql.gz 压缩包，不用先解压：

gunzip < backup.sql.gz | mysql -u root -p 数据库名

管道把解压和导入串起来，省磁盘空间也省时间。

PostgreSQL：psql 的 -f 参数

PostgreSQL 用 psql 导入，逻辑类似但命令不同：

psql -U postgres -d 数据库名 -f /path/to/backup.sql

这里 -f 是指定文件。如果备份是 .dump 格式（用 pg_dump -Fc 生成的），得用 pg_restore：

pg_restore -U postgres -d 数据库名 /path/to/backup.dump

有个坑：pg_restore 默认不建库，目标数据库得提前存在。我第一次用的时候没注意，报错“database does not exist”，愣了半天才反应过来。

SQLite：一个命令搞定

SQLite 最简单，因为它本身就是个文件。导入 SQL 文件：

sqlite3 你的.db < backup.sql

或者进入交互模式后用 .read：

sqlite3 你的.db sqlite> .read backup.sql

SQLite 没有用户和权限的概念，所以省去了密码那一步。但要注意，如果 .db 文件已经存在且有数据，导入的 SQL 里如果有 CREATE TABLE 同名表会报错。要么先删掉旧文件，要么在 SQL 里加 IF NOT EXISTS。

MongoDB：mongoimport 和 mongorestore

MongoDB 分两种情况。如果是 JSON 或 CSV 文件：

mongoimport --db 数据库名 --collection 集合名 --file data.json

如果是 mongodump 生成的 BSON 备份目录：

mongorestore --db 数据库名 /path/to/dump/数据库名

MongoDB 的坑在于版本兼容。用 5.0 的 mongodump 导出的数据，往 4.4 的 mongorestore 里灌，有时会报 BSON 版本不匹配。我一般建议导出和导入用同一个大版本。

几个容易翻车的地方

字符集。MySQL 导入时如果文件是 UTF-8 但数据库默认 latin1，中文会变问号。导入前确认两边一致，或者在命令里加 --default-character-set=utf8mb4。

权限。导入到远程数据库时，用户得有 CREATE、INSERT 等权限。只给 SELECT 权限的账号导入必然失败，报错信息还经常含糊其辞。

大文件超时。用图形工具导入大文件时，连接超时设置太短会导致中途断开。命令行没这个问题，但如果走网络导入，max_allowed_packet 参数可能限制单条 SQL 语句的大小，需要提前调大。

说到底，导入数据库就是个“把数据倒进去”的动作。命令行比图形界面可靠，提前确认字符集和权限能省掉八成麻烦。文件再大，命令敲对了也就是等几分钟的事。