干这行十多年，最怕听到的一句话就是“库挂了”。比这更让人血压飙升的，是接下来的那句“有备份吗”。说实话，我见过太多开发兄弟，写SQL溜得飞起，一到恢复数据库就手忙脚乱，要么翻GUI工具点半天，要么干脆对着黑漆漆的终端发愣。今天这篇，不扯虚的，就把MySQL命令行恢复这摊子事儿，掰开揉碎了讲清楚。你只要照着敲，哪怕半夜三点被叫起来，也能稳得住。
很多人一提恢复，第一反应就是命令。没错，，这招对付小库绰绰有余。但你有没有想过，如果备份文件是压缩过的呢？比如DBA们常用的。这玩意儿的好处在于，不用先解压出中间文件，直接流式导入，省磁盘空间，速度还快。我见过不少新手，辛辛苦苦解压出几个G的SQL文件，然后磁盘满了，那叫一个欲哭无泪。
光会导入不算本事，关键时候你得会挑着恢复。比如线上库几百张表，你只是误删了一张表的数据，傻子才把整个库导回去。这时候MySQL的命令行就显出灵活性了。如果你备份时用了参数，那SQL文件里会包含和语句，你没法直接挑表。但如果你备份时用了，那就好办了。你可以先建一个临时库，把备份导进去，然后用单表导出来，再导入正式库。听着绕，但实际操作就三条命令的事，总比全量恢复折腾半天强。记住，恢复的第一原则是精准打击，不是地毯式轰炸。
说到速度，这里头有个容易被忽略的坑：默认的命令，或者重定向导入，其实是单线程的。你要是导一个大库，几百万行的数据，那速度慢得能让你盯着屏幕怀疑人生。怎么提速？两个思路。第一，导入前先关掉外键检查和唯一性检查，用和。这俩命令在导入前执行，能省下大量校验时间。第二，如果你的备份文件是逻辑备份（就是纯SQL），你可以考虑用配合文本格式的数据文件，那玩意儿是并发导入的，速度能翻好几倍。但前提是你得有对应格式的文本文件，一般配合参数能导出这种格式，不过这是另一个话题了，今天点到为止。
还有一种情况，估计不少人都遇到过：备份文件里带着语句，导入的时候权限不够，直接报错。这破事我当年栽过跟头。解决思路很简单，别用重定向了，改用命令的参数，先执行，然后再用去导入。这个参数是个救命稻草，它能让SQL语句即使出错也继续执行，不会因为中间一个错误就整体停止。当然，前提是你得清楚哪些错误可以忽略，哪些错误会要命。比如重复插入的错误，用就能跳过去，但如果是语法错误，那还得回头查备份文件。
再讲个实战细节，关于字符集的。很多恢复失败或者恢复后数据乱码，问题都出在字符集不匹配上。命令行导入时，一定要用（或者你库原来的字符集）显式指定。别以为备份文件里写了就万事大吉，有时候终端环境的默认字符集是，导入时就会出岔子。我习惯的做法是，导入前先看备份文件头部，确认字符集设置，然后命令行里强制指定。这习惯救了我好几次，尤其是处理那些从老系统迁过来的数据，各种编码混在一起，不指定字符集，恢复出来的数据就是一堆问号，哭都没地方哭。
另外，千万别小看恢复后的校验工作。命令行导入完，显示不代表万事大吉。你得快速验证一下数据行数是否对得上。比如备份文件里开头会有这样的注释，你可以一下备份文件，数数里面插入了多少行，然后导入后查一下。如果对不上，说明导入过程有丢失。还有一招，用命令检查表完整性，这工具能帮你检测出损坏的表。我见过有人导入完，表能查，但一就报错，一查才发现索引丢了。所以，恢复不是终点，校验才是闭环。
说句掏心窝子的话。命令行恢复，看着土，看着不酷，但它最可靠，最不依赖环境。图形化工具界面再好看，底层调用的还是这些命令。你把这几个招数学会了，走到哪儿都不慌。而且，命令行有个好处是能写脚本，你可以把恢复流程封装成一个脚本，下次出问题，一键执行，连脑子都不用动。记住，恢复数据库这事儿，快是第一位的，稳**是第二位的，至于好不好看，没人关心。把这篇文章里讲的几个点——压缩文件处理、精准恢复、并发提速、字符集指定、校验闭环——记在心里，下次真遇到事，你就能体会到什么叫“手里有粮，心里不慌”了。
