干这行这么多年，最怕听到的就是那句“卧槽，数据呢？”。MySQL崩了、误删了表、硬盘坏了，那一瞬间的心跳加速和冷汗，比任何恐怖片都刺激。但你得知道，数据没了不等于判了死刑，MySQL这老伙计虽然脾气倔，但留的后门也不少。今天咱不整那些虚头巴脑的理论，直接聊实操，把你那点压箱底的数据，从鬼门关里拽回来。
先说最基础的，也是你天天用但危机时刻最先想起来的——逻辑备份。mysqldump这家伙，平时看着笨重，关键时刻是真救命。如果你之前规规矩矩跑了，那恢复就简单了，直接，一把梭。但这里有个坑，很多人备份时不带，InnoDB表还好，MyISAM表备份过程中有写入，备份文件就是脏的，恢复时直接报错或者数据逻辑错乱。所以，恢复前先看看备份文件开头，有没有和这些正常标记，再用扫一眼，心里有个底再动手。纯文本SQL文件的好处是能改，如果你只误删了一张表，别傻乎乎全量恢复，用或者文本编辑器把那一段和对应的抠出来，单独执行，效率翻倍。
但现实往往更操蛋，你根本没做备份，或者备份文件是半个月前的。这时候就得靠二进制日志，也就是binlog，这玩意儿是MySQL的“黑匣子”，记录了你每一次写操作。前提是你开了，没开的话，恭喜你，只能去烧香了。恢复思路是这样的：先找到最近一次全量备份，恢复到那个时间点，然后从binlog里把从备份结束时间点到故障发生时间点的所有操作，重新回放一遍。具体命令是。注意，回放binlog前一定要先确认，你误删的那个语句在不在里面，如果在，你得用加参数，或者先编辑日志文件把那条危险的SQL去掉，否则你等于把错误又执行了一遍，那才叫欲哭无泪。
要是连binlog都没开，或者日志文件也损坏了，那就得指望物理层面的恢复了。这时候，InnoDB引擎的存储文件——和这些家伙就派上用场了。如果你只是MySQL服务起不来，但数据文件还在，先别急着重装系统，试着把整个目录复制到另一台机器上，用相同版本的MySQL启动，很多时候只是系统库表损坏，业务数据是完好的。如果启动报错，试试参数，从1调到6，每调一档就尝试启动一次，这参数是让InnoDB跳过各种校验和崩溃恢复，虽然可能损失部分数据，但总比全部打水漂强。记住，调这个参数后，数据库是只读模式，千万别做写操作，赶紧把数据导出来。
还有一种情况，表文件还在，但结构乱了，或者你删了表但用删的，物理文件直接没了。这时候，如果你用的是Linux，而且文件系统是ext4或者xfs，赶紧停掉所有写入操作，用或者去扫描磁盘块。这招纯靠运气，因为MySQL的数据文件是预分配的，删除后那些块很可能被标记为可复用，但只要没有新数据覆盖，还是有机会捞回来的。操作步骤不复杂，分区后，用，但前提是你得有root权限，而且动作要快，时间越久，被覆盖的风险越大。
再说说那些云数据库，比如RDS或者云厂商的MySQL托管。很多新手以为云上就绝对安全，错了。云上照样有误删、误更新，而且你连物理文件都摸不着。这时候，你得靠云厂商的“备份恢复”和“按时间点恢复”功能。阿里云、腾讯云这些都有控制台操作，恢复到几分钟前没问题。但有个细节，恢复前一定看清楚，是按“最近备份点”恢复，还是“自定义时间点”恢复，选错时间，你又得折腾一遍。另外，云上恢复出来的实例，往往是新地址，记得改应用配置，别恢复完了，应用还连老库，白忙活。
说点掏心窝子的经验。以上所有技巧，核心都围绕一个词——备份。但备份不是跑了cron就完事了，你得定期做恢复演练。我见过太多公司，备份脚本跑了两年，从没验证过，结果真出事那天，恢复出来的SQL文件是0字节，或者缺了半张表，那才叫绝望。还有，恢复操作最好在测试环境先跑一遍，别直接在生产库上试，万一恢复命令写错了，本来能救的也被你搞死了。如果数据实在重要，找专业的数据恢复公司，他们用底层工具直接读磁盘扇区，但价格嘛，够你买好几台新服务器了。MySQL数据恢复这活儿，七分靠备份习惯，三分靠临场操作，平时多留一手，真出事时你才能稳住心态，按部就班把数据捞回来。
