干这行久了，谁还没个手滑的时候。前几天凌晨三点，我一个做电商的朋友打电话过来，声音都在抖——他把生产库的表删了，备份倒是做了，但恢复的时候死活报错，客户那边凌晨大促还在跑数据。我远程看了一眼，他用的命令是，看着没毛病，但报错信息是"Unknown command '''"——多半是备份文件里混了Windows换行符，或者字符集没对上。这种事儿太常见了，所以今天不聊那些虚头巴脑的理论，直接讲讲我这些年踩过的坑和真正管用的命令。
先说最基础的恢复命令，，这招适用于逻辑备份，也就是mysqldump导出来的文件。但很多人不知道，如果备份文件里包含了建库语句，你恢复的时候就不用指定数据库名，直接就行，否则会报"Unknown database"错误。还有个小细节，如果你备份时用了参数，恢复时千万别再指定库名，不然等于把数据导进了同名的另一个库，回头查数据全没了，那才叫欲哭无泪。
再说说物理备份的恢复。如果你用的是直接拷贝数据目录，或者用了这类工具，恢复方式完全不一样。xtrabackup恢复分两步：先把日志回放，让数据文件保持一致，然后再把数据拷回MySQL的数据目录。这里有个坑，拷贝之前必须确保MySQL服务是停的，而且数据目录得是空的，否则会覆盖现有文件，连后悔药都没得吃。我见过有哥们儿没停服务就copy-back，结果MySQL直接起不来，InnoDB报corruption，只能从头再来。
说到误删数据恢复，得提一嘴binlog。如果你开启了binlog，并且删数据之前有完整备份，那就可以用来追回。比如你凌晨3点误删了一张表，备份是昨天晚上的，那恢复流程就是：先恢复昨晚的备份，然后用把这段时间的增量操作重放一遍。但这里有个大坑，binlog里也包含了你误删的那条DELETE语句，你得用定位到删除操作之前的位置，或者用参数过滤掉特定库表。我上次帮人恢复，就是因为没过滤，结果删了两次，数据彻底没了，那叫一个惨。
字符集问题也是恢复时的高频坑。备份文件里如果有中文，恢复时乱码，十有八九是字符集没指定。恢复命令后加，同时确认你的表结构也是utf8mb4，否则就算命令对了，数据进去了也是问号。还有更隐蔽的，如果备份文件是用导出的，恢复时得用同样的参数，不然二进制数据会损坏。我建议恢复之前先看看文件头的注释，里面通常会写明导出时的字符集和参数，照着来基本不会错。
再讲个冷门但实用的命令——。如果你已经登录进MySQL客户端了，不想退出再用重定向，可以直接在mysql>提示符下执行。这招的好处是能看到每一条SQL的执行结果，报错能立刻发现。坏处是如果备份文件很大，终端会刷屏刷到怀疑人生，而且中断之后没法断点续传。所以我一般建议，超过1GB的备份文件，还是用重定向方式，配合在后台跑，输出日志写到文件里，回头慢慢看。
还有种情况，你手上只有部分备份或者备份文件损坏了，这时候得用或者来救急。可以尝试修复MyISAM表，InnoDB的表如果损坏，得在配置文件里加（数值可以调到6，但级别越高越危险，能导出来数据就赶紧导），然后启动MySQL，用把能导的数据都导出来，再重建实例。记住，这招是保底用的，别指望能100%恢复，能救回多少算多少。
说个很多人忽略的点——恢复完一定要验证，别急着跟老板汇报"搞定了"。恢复完跑一下对比备份时的行数，再看一下关键表的索引是否完好。我习惯恢复完直接执行，确认状态是OK。之前有个同事恢复完数据看着都在，但业务跑起来巨慢，一查索引全丢了，等于恢复了裸表。所以验证这步别省，省了后面更麻烦。
说实话，恢复数据库这事儿，90%靠平时准备，10%靠临场发挥。备份策略再完善，恢复命令不熟练照样抓瞎。我建议你找个测试库，把上面这些命令都练一遍，特别是binlog恢复那套流程，多模拟几次误删场景。真到了生产环境出事那天，你会感谢自己当初多练的那几遍。毕竟数据这东西，没了就是没了，哭都来不及。
