前两天帮一个朋友处理数据库恢复的事，他误删了表结构，急得直跳脚。我远程过去，用 MySQL 的 命令把备份的 SQL 文件导回去，前后不到十分钟搞定。这让我想起刚入行时，第一次面对几 GB 的 SQL 文件，手忙脚乱折腾了一下午。其实 MySQL 恢复 SQL 文件这事儿，说难不难，说简单也得懂点门道。
最常见的恢复方式就是 MySQL 命令行。打开终端，登录到 MySQL，用 命令选中目标数据库，然后执行 。这招对中小文件特别管用，几 MB 到几百 MB 的文件基本秒杀。需要注意一点：SQL 文件里如果包含建库语句， 之前得确保目标库不存在，或者直接让文件自己建库。我见过有人 完后一脸懵，发现数据跑到默认库去了，就是因为文件开头写了 ，而他又手动建了一个同名的库，两边打架。
不过文件一旦超过 1 GB， 就开始吃力了。MySQL 默认的 参数只有 4 MB，大文件导进去会报 “packet too large”。这时需要调大参数，要么在配置文件里改后重启服务，要么直接在会话里 。我处理过一个 8 GB 的电商订单备份， 跑了半小时报错，后来发现是某条超大 语句撑爆了包限制。改完参数后，又遇到另一个坑——SQL 文件里如果有特殊字符（比如中文注释或 emoji），字符集不对会直接中断恢复。
所以大文件恢复，我更推荐用 MySQL 命令行直接重定向。语法很简单：。这种方式不经过 MySQL 客户端解析，直接由服务端接收，速度比 快好几倍。去年帮一家公司恢复 200 GB 的备份，用 估计得跑一天，改用重定向后，四个小时就搞定了。不过重定向有个陷阱，密码写在命令里会被记录到 history，安全敏感的环境最好用 预先配置登录信息。
还有一种场景是 SQL 文件特别大，比如超过 50 GB，而服务器内存有限。这时直接重定向可能把内存撑爆，因为 MySQL 会尝试把整个文件读入缓冲。我遇到过一个极端案例，客户的服务器只有 4 GB 内存，要恢复 60 GB 的备份，一执行就 OOM。解决办法是分片恢复，用 把大文件拆成若干个小块，每个约 1 GB，按顺序逐个导入。另一个技巧是禁用二进制日志，，这样恢复过程不会写入 binlog，能省下大量磁盘 I/O 和 CPU 资源。
日常开发中还有一种情况，就是 SQL 文件不完整或有损坏。比如从生产环境导出的备份，传输过程中丢了几行数据，这时直接恢复会报错，需要先用 或 清洗文件。我处理过一个案例，备份文件里出现了乱码的二进制数据，导致 语句中断。用 的正则把无效行过滤掉，再补上缺失的逗号和括号，才恢复成功。这种手工修文件的操作很考验对 SQL 语法的熟悉程度，所以平时写备份脚本时，最好加上校验机制，比如生成 MD5 值或记录行数。
其实还有个小众但好用的工具——。它是 MySQL 5.7 之后引入的并行备份恢复工具，导出的 SQL 文件自带进度信息和错误处理，恢复时能自动跳过有问题的行并给出日志。不过大多数生产环境仍在使用 ，毕竟老工具更稳定可靠。我的习惯是：小文件用 ，大文件用重定向，超大文件用分片加 MySQL 命令行。每种方法都有适用场景，就像工具箱里的螺丝刀和扳手，看情况选。
说个容易被忽视的细节：恢复前一定要检查目标数据库的存储引擎。如果是 InnoDB，记得把 设为 0，手动控制事务提交，这样能大幅提升恢复速度。MyISAM 可以临时禁用键检查， 和 ，等数据全部导入后再重建索引。前阵子有个同事恢复 500 万行数据的备份，没关外键检查，结果每插入一条都要检查关联表，跑了整整两天。关掉检查后，同样的数据只用了半小时。
所以你看，MySQL 恢复 SQL 文件这事儿，核心就三点：选对工具、调好参数、注意细节。别被那些花里胡哨的图形界面工具忽悠了，命令行才是最可靠的。下次遇到数据库崩溃，别慌，先看看文件大小，再判断用什么方式。实在不行，还有一张底牌——用 解析二进制日志，把数据恢复到误操作前的某个时间点。不过那是另一个话题，今天先聊到这儿。
