上周我接到一个老朋友的电话，他说公司服务器突然崩了，数据库里的订单数据全丢了。电话那头声音都变了，毕竟那是几千个客户的交易记录。我问他有没有备份，他说有啊，每周都导出一个SQL文件。我一听就放心了，因为MySQL恢复SQL文件这件事，操作起来比想象中简单得多。只要文件还在，数据基本都能找回来。这事儿让我想起很多创业公司或者小团队，平时不注意备份，出了事才慌。其实只要养成定期导出SQL文件的习惯，遇到服务器挂了、硬盘坏了这些意外，照样能靠着这个文件把数据库恢复得原封不动。
很多人觉得恢复SQL文件是个高深的技术活，其实不然。说白了，SQL文件就是一系列SQL语句的文本集合，里面包含了建表、插入数据、修改记录这些操作。当你执行这个文件的时候，MySQL会逐行读取并执行这些语句，相当于把当初创建数据库的过程重演一遍。最常见的场景是你从phpMyAdmin、Navicat这些工具导出了一个SQL文件，然后想导入到另一台服务器。这时候你只需要打开命令行，敲一行source命令就行。比如我常用的是，输入密码后文件就开始跑了。如果文件不大，几秒钟就完事。
实际操作中，最让人头疼的是文件太大。有一次我帮一个电商平台恢复数据，那个SQL文件足足有5个GB，直接在命令行导入，跑了两个小时还在卡着。后来我查了一下，发现问题出在MySQL的配置上。默认情况下，MySQL的maxallowedpacket参数设置得比较小，大文件导入时会被截断。解决办法很简单，编辑my.cnf或者my.ini文件，把这个值调大到256M或者512M，重启MySQL服务再试，速度立马快了好几倍。还有一个坑是字符集不匹配。如果你从旧服务器导出的文件用的是latin1编码，而新服务器默认是utf8mb4，恢复时中文就会变成乱码。解决方案是在导入前用指定编码，或者直接在source命令前加一句。
遇到文件损坏的情况怎么办？别急，SQL文件虽然是个文本文件，但结构很规整。我有个朋友从云服务器下载备份时网络中断，文件后半部分全没了。他拿过来一看，文件末尾缺了commit语句和一些外键约束。这时候手工补上缺失的部分就行。比如找到一条INSERT语句，手动加上分号和COMMIT，再补上SET FOREIGNKEY_CHECKS=1。如果文件中间有损坏，可以先用命令过滤出错误的行，比如搜索“ERROR”或者“Duplicate entry”这些关键词，定位到问题所在。更狠一点的办法是用命令直接把错误行删掉，然后重新导入。当然，这需要你对SQL语法比较熟悉，不然删错了数据就真的回不来了。
还有一种情况是SQL文件里有大量重复数据。比如你从旧服务器导出时没去重，导入新库时报“Duplicate entry”错误。这时候不能直接忽略，因为错误积累多了会导致导入中断。我的做法是先修改SQL文件，在INSERT语句前加上，这样遇到重复数据就跳过，不影响后续导入。或者更彻底一点，先用把重复数据清理掉再导出。如果是生产环境，最好在导入前先用测试库跑一遍，看看有没有异常。我记得有次帮人恢复一个会员系统，文件里有几十万条记录，跑完后发现会员等级字段全成了NULL，原来是导出时字段顺序搞错了。还好提前发现了，不然客户登录看到等级丢了，投诉电话得打爆。
恢复过程中，权限问题也经常冒出来。比如你用root账号导出的SQL文件，里面可能包含了创建用户、授权等语句。如果新服务器上root密码不同，执行到GRANT语句时就会报错。解决方案是在导入前手动注释掉这些语句，或者用批量替换。更稳妥的做法是单独导出数据和结构，不导出用户权限。比如用mysqldump时加上参数，只导出数据。或者分两步走：先用导出结构，再用导出数据。这样即使权限不对，也能先把表结构和数据恢复好，回头再单独处理用户权限。
说一千道一万，最好的恢复策略还是预防。我见过太多人把SQL文件扔在服务器上，结果服务器挂了文件也没了。正确做法是把备份文件下载到本地，或者上传到阿里云OSS、腾讯云COS这种对象存储里。最好设置一个定时任务，每天凌晨自动导出并压缩，然后上传到云端。压缩后的SQL文件体积能减少70%以上，传输也快。另外，恢复前一定要检查文件完整性。可以用或者计算文件的哈希值，跟备份时记录的比对一下，确保文件没被篡改或损坏。如果文件太大，还可以用命令分割成小块，分批导入，这样即使某块出错，也不会影响其他部分。
说个真实案例。去年有个做跨境电商的朋友，数据库被黑客删了，连备份文件都被清空了。好在他们之前用mysqldump导出了一个全量SQL文件，存在公司内网的NAS上。我远程帮他恢复，过程很简单：先在新服务器上创建同名数据库，然后用命令导入。文件有3个GB，跑了大概20分钟。恢复后检查数据，发现少了最近两天的记录。这是因为他们的备份策略是每晚一次，黑客在凌晨动的手。后来我建议他们改成每小时增量备份，用binlog来实现。虽然多花了点存储成本，但至少数据丢失风险从24小时降到了1小时。这个教训告诉我们，恢复SQL文件虽然不难，但备份策略的合理性才是数据安全的基石。
