上周帮朋友恢复一个电商后台的入数订单表，他用 phpMyAdmin 导出的据库 SQL 文件只有 2MB，却在导入时反复报 “MySQL server has gone away”。入数查了半天，据库问题出在 max_allowed_packet 默认值太小，入数而他服务器上跑的据库是 MySQL 5.7，配置文件里那个参数还停留在 4M。入数改完重启，据库三秒导入完成。入数这种事遇多了就会发现，据库导入数据库失败，入数八成不是据库 SQL 写错了，而是入数环境没对上。

命令行导入是据库最稳的方式，没有之一。入数把 .sql 文件丢到服务器上，cd 到对应目录，执行：

mysql -u root -p database_name < backup.sql

注意 database_name 必须提前建好，字符集建议跟原库一致。我见过有人用 utf8mb4 导出的文件往 latin1 的库里灌，中文全变问号，还以为是文件损坏。如果 SQL 文件里没写 USE database_name，那命令里的库名就是唯一依据，漏了直接报 “No database selected”。

文件特别大怎么办？比如超过 1GB 的备份。用 source 命令进交互模式：

mysql -u root -p mysql> use target_db; mysql> source /path/to/bigfile.sql;

这样能绕过 shell 重定向的一些限制，而且出错时会停在具体行号，方便排查。但 source 不支持管道，速度比直接重定向慢一点，大文件得有耐心。

phpMyAdmin 适合小库，超过 50MB 就悬了。它受 PHP 的 upload_max_filesize、post_max_size、max_execution_time 三重限制。改 php.ini 能解决，但改完记得重启 PHP-FPM 或 Apache。有个取巧办法：把 SQL 文件用 gzip 压缩，phpMyAdmin 支持导入 .sql.gz，体积能缩到五分之一。不过压缩包里的 SQL 如果包含 DELIMITER 自定义分隔符，phpMyAdmin 解析时容易出错，这点不如命令行可靠。

字符集问题值得单独说。导出时用 mysqldump --default-character-set=utf8mb4，导入时客户端也要指定同样字符集。否则可能出现“库是 utf8mb4，表是 utf8，连接是 latin1”的混乱局面。有个快速判断方法：导入后随便查一条含中文的记录，如果显示正常，基本没问题；如果显示乱码但 phpMyAdmin 里看又是好的，那多半是连接字符集没设对。

还有外键约束的坑。导入顺序不对，或者 SET FOREIGN_KEY_CHECKS=0 没加在文件开头，就会报 “Cannot add or update a child row”。mysqldump 默认会加这个设置，但手动导出的文件经常漏掉。我的习惯是在导入前先执行：

SET FOREIGN_KEY_CHECKS=0; -- 导入内容 SET FOREIGN_KEY_CHECKS=1;

如果 SQL 文件本身没带这两句，可以临时用 sed 在文件头尾插入，或者导入时用 --init-command 参数。后者更干净，不污染原文件。

最后提一个真实案例。某次从云数据库 RDS 导出备份到本地 MySQL，导入后所有时间字段都差了 8 小时。原因是 RDS 默认 time_zone 是 UTC，本地是 CST。SQL 文件里存的是 UTC 时间戳，导入后 MySQL 按本地时区解释。解决办法是在导入前执行 SET time_zone='+00:00'，或者导出时加 --tz-utc=false。这种问题不会报错，但数据悄悄偏移，比导入失败更危险。

导入完别急着走。跑一句 SELECT COUNT(*) 对比源库和目标库的行数，再抽查几张核心表的数据。我一般还会用 CHECK TABLE 快速验证一下 InnoDB 表的完整性。花两分钟，省得后面返工。