凌晨三点，手机震了。电话那头，同事声音发颤：“MySQL崩了，起不来了，今天早上业务还要用。”说实话，干这行这么多年，听到“数据库崩了”这五个字，比听到“家里水管爆了”还让人头皮发麻。水管爆了最多淹了地板，数据库崩了，可能把整个公司的命脉都掐断了。但别慌，崩溃不等于死刑，大部分情况都能救回来，关键是别在慌乱中瞎操作，把本来能救的数据给二次破坏了。
先说最要命的一条规矩：数据库崩了，第一时间别重启。很多人条件反射就去敲，或者直接重启服务器，这其实是最危险的动作。MySQL崩溃分好多种，有的是配置文件写错起不来，有的是存储引擎损坏，有的是磁盘满了，还有的是数据页错乱。如果是InnoDB的redo log或者数据文件出了问题，重启可能会触发崩溃恢复流程，有时候能自动修好，有时候反而会加重损坏。正确做法是，先看错误日志，一般都在或者下的文件里，那里面会写明崩溃原因，这是你判断下一步怎么走的第一手情报。
如果是配置文件的问题，比如里写了个不存在的参数，或者权限不对，这种最简单，改回来就能启动。但如果是InnoDB数据页损坏，那就要动真格的了。这时候，先别碰原库，把整个数据目录拷贝一份出来，磁盘空间够的话直接，不够的话用。备份完之后，在备份上操作，原目录留着别动。为什么？因为你试错的过程可能会产生新的写入，一旦把原数据弄脏了，神仙难救。记住这句话：没有备份的操作都是耍流氓，尤其是数据库恢复，每一步都要留退路。
接下来聊点实际的恢复手段。如果是单表损坏，而且你用的是MyISAM引擎，那能救不少场景。但现在是InnoDB的天下，InnoDB的表损坏，基本上不管用。这时候有几个思路：一是用把能导出的表先导出来，如果整个库起不来，可以试试在里加上，这个参数从1到6，数字越大，跳过的东西越多，但数据丢失的风险也越大。一般先从1开始试，能起得来就赶紧，把数据捞出来，然后重建实例导回去。记住，这个参数只是让你“抢救性访问”，不是让你长期跑业务的，捞完数据立刻改回来。
如果你的表是分区表，或者数据量特别大，时间太长，那可以考虑直接拷文件。前提是表结构还在，你可以用和来把文件挂回去。但这个操作对版本一致性要求很高，如果源库和目标库的MySQL版本不一致，或者设置不同，很容易失败。更稳妥的办法是用工具提取表结构信息，或者用Percona的工具，不过这些对普通DBA来说门槛有点高。我自己的经验是，能用解决的，就别折腾文件级恢复了，省事第一。
还有一种情况，不是数据文件坏了，而是你误操作了——比如、，或者没加条件。这种时候，如果你开了，那恭喜你，有救。用工具把binlog解析出来，找到误操作的时间点，把那段SQL反向执行。比如你了一张表，那就从binlog里把建表语句和语句捞出来重新执行。如果你开了模式，定位会更精准。但这里有个坑：binlog也有过期时间，默认可能只保留几天，所以误操作之后发现得越早越好，晚了就真的找不回来了。这也是为什么我一直强调，生产环境必须开，哪怕你觉得用不上。
再说一个很多人忽略的细节：磁盘满了导致的“伪崩溃”。MySQL写着写着发现磁盘没空间了，会直接报错甚至宕机。这种时候别急着恢复，先清磁盘。把下的老日志清一清，把里已经备份过的删掉一些，或者把挪到有空间的分区。清理完之后再尝试启动，往往就好了。但要注意，如果或者已经因为磁盘满而写了一半，那启动时可能会触发回滚，这时候耐心等，别中途再杀进程。我见过有人等不及，直接，结果把回滚过程打断，数据文件彻底乱了，只能从备份恢复。
说一句扎心的实话：最好的恢复手段，是你压根用不上恢复手段。定期备份，备份要验证，不能只备份不测试恢复。很多公司备份脚本是写了，但从来没演练过恢复，真出事那天，发现备份文件是坏的，或者恢复步骤根本不对，那才叫欲哭无泪。全量备份加上增量备份，这套组合拳打好了，数据库崩了也就是个半小时的活。另外，用这类物理备份工具，恢复速度比逻辑备份快得多，适合大库。但不管用哪种，至少每季度做一次恢复演练，确保备份不是摆设。数据库崩了不可怕，可怕的是你连怎么救都不知道，或者救到一半把数据彻底搞没了。把这篇文章存下来，真出事的时候，照着步骤一步步来，别慌，能救回来的。
