数据库崩了，你的第一反应是什么？别慌，MySQL命令恢复数据库这事儿，其实没那么玄乎。我见过太多人遇到数据表打不开、查询报错就急着删库跑路，结果把能救的数据彻底搞死。今天咱们就手把手过一遍，从最基础的应急检查到实战修复，一个命令地拆开讲清楚。
先说最典型的场景：你正在跑业务，突然MySQL报错“Table ‘xxx’ is marked as crashed and should be repaired”。别急着骂服务器，这其实是MySQL在告诉你，某个表的数据文件出了点小毛病。第一步，先用CHECK TABLE命令确认损坏程度。打开命令行，输入，或者直接进MySQL后执行。这个命令会返回一个状态，告诉你表是OK的，还是需要修复。注意看结果里的Msgtext字段，如果显示“Table is marked as crashed”，那就赶紧进入下一步。
真正动手修复，推荐用REPAIR TABLE命令。这是MySQL自带的轻量级修复工具，对付索引损坏或者小范围数据错乱特别管用。在MySQL命令行里输入，默认是快速修复模式，只修复索引结构。如果不行，加上扩展参数：。这个命令会强制用.frm表结构文件重建表，但前提是你的.frm文件没坏。我去年帮一个电商客户恢复订单表，就是用这个命令救回来的，原本以为要丢三天数据，结果五分钟搞定。注意，REPAIR TABLE执行期间会锁表，生产环境建议先停掉业务写入。
如果REPAIR TABLE也救不了，别放弃，试试mysqlcheck的扩展模式。直接在shell里跑：。这个命令会遍历数据库里所有表，自动检测并修复。--extended参数会尝试深度修复，包括重写数据文件和索引文件。但有个坑：如果你的表是MyISAM引擎，这个命令效果很好；如果是InnoDB，修复能力有限，因为InnoDB的事务日志和双写缓冲机制本身就自带一定容错。我遇到过一个案例，客户用InnoDB表频繁报错，结果跑完mysqlcheck发现只是临时表空间坏了，重启服务后一切正常。
说到InnoDB，这个引擎的修复思路跟MyISAM完全不同。InnoDB最常用的修复命令是。别被名字骗了，这个命令不是改引擎，而是强制InnoDB重建表。它会读取旧的表空间文件，重新创建索引和数据页，同时修复内部结构。如果这个命令报错，说明表空间文件本身已经严重损坏，这时候需要动用参数。修改MySQL配置文件，在[mysqld]下加一行，重启数据库。这个参数从1到6，数字越大，恢复模式越激进，但数据可能丢失更多。建议先设成1，看看能不能启动；不行再逐级增加。我见过有人直接设成6，结果数据库倒是启动了，但表里只剩一半数据，因为跳过太多检查步骤。
万一你的表结构文件.frm也损坏了，或者整个数据库目录乱成一锅粥，这时候需要祭出mysqlbinlog。这个命令是MySQL的二进制日志解析器，可以回放所有历史操作日志。先找到二进制日志文件，一般在/var/lib/mysql/目录下，名字是mysql-bin.001这种。执行，就能把日志里的操作重新执行一遍。但注意，这个命令会把日志里所有操作都回放一遍，包括你之前误删数据的操作。所以更聪明的做法是，先用导出到SQL文件，手动编辑去掉错误操作，再导入。我有个朋友就是靠这招，把不小心drop掉的数据表恢复到了误操作前的状态。
提醒几个关键点：第一，任何修复操作前，先备份。备份命令很简单：。哪怕你的数据库半死不活，只要还能启动，就用mysqldump把能读到的数据导出。第二，修复时尽量用命令行工具，别用phpMyAdmin这类图形界面，因为图形界面容易超时，而且很多底层命令不支持。第三，如果修复过程中数据库反复重启，检查一下磁盘空间和内存占用，有时候问题根本不是数据损坏，而是磁盘满了导致写入失败。第四，养成定期检查的习惯，每周跑一次，防患于未然。数据库这玩意儿，平时多做一分功夫，出事儿时少掉十成头发。
