MySQL表坏了别慌，这些方法能帮你巧妙修复数据不丢失

“MySQL表坏了别慌，这些方法能帮你巧妙修复数据不丢失”

数据库用久了,难免会遇到一些意外情况，服务器突然断电，或者硬盘空间不足，再或者MySQL服务在运行中被强制结束，都可能导致数据表损坏，出现一些莫名其妙的错误，当你尝试去查询一张表时，屏幕上突然跳出“Table 'xxx' is marked as crashed and should be repaired”这样的报错信息，心里肯定会咯噔一下，别着急，这种情况虽然棘手，但只要处理得当，绝大部分数据都是可以救回来的，今天我们就来聊聊几种实用的修复方法，让你在遇到问题时心里有底。

最重要的一步永远不是马上动手修复,而是备份，无论表损坏到什么程度，只要条件允许，第一反应就应该是想办法把当前的数据文件备份出来，哪怕是一个损坏的文件，也比贸然修复导致二次破坏要好，你可以直接复制整个数据库的数据目录（通常是/var/lib/mysql/你的数据库名/），或者如果表还能勉强读取部分数据，尝试用mysqldump命令导出，即使导出过程会报错，也能救回一部分数据，这一步是最后的保险绳。

我们可以尝试一些MySQL自带的修复工具,最简单直接的方法是使用mysqlcheck命令，这是一个非常方便的命令行工具，你可以在服务器上执行类似这样的命令：mysqlcheck -u root -p --auto-repair --check 你的数据库名 损坏的表名。（根据MySQL官方文档关于mysqlcheck工具的说明）输入密码后，它会自动检查表并尝试修复。--auto-repair参数就是让它发现问题自动处理，非常省心，如果这个命令能成功，那问题就基本解决了。

如果mysqlcheck搞不定，或者你想更深入地控制修复过程，可以进入MySQL的命令行客户端，使用REPAIR TABLE语句，直接输入REPAIR TABLE 表名;（参考MySQL官方文档中SQL语句REPAIR TABLE的章节），这条命令会尝试用默认的方式修复表，它会提示修复失败，但会给出其他建议，比如建议使用USE_FRM选项，这时候，你可以尝试更强大的REPAIR TABLE 表名 USE_FRM;，这个选项的含义是使用表的结构定义文件（.frm文件）来重新构建索引，适用于索引损坏严重但数据本身可能还完好的情况，但要注意，USE_FRM有一定风险，使用时最好确保你的MySQL版本没有变动。

当上述两种SQL层面的方法都无效时,我们就需要动用底层的“武器”了——myisamchk工具，这个工具是专门针对MyISAM存储引擎表的，直接操作磁盘上的数据文件，所以威力很大，但风险也相对较高。在使用myisamchk之前，务必确保MySQL服务已经完全停止，否则会造成更严重的损坏，停止服务后，进入对应数据库的目录，然后执行命令，基本的修复命令是myisamchk -r 表名.MYI，这里的-r代表恢复模式，如果不行，可以尝试更彻底的myisamchk --safe-recover 表名.MYI，或者最强大的myisamchk -f -r 表名.MYI（-f是强制操作）。（该方法源于MySQL官方对于myisamchk工具的说明）这个过程可能会比较慢，需要耐心等待，修复完成后，再重新启动MySQL服务。

还有一种情况是表的结构定义文件（.frm文件）损坏或丢失了，但数据文件（.MYD）和索引文件（.MYI）可能还是好的，这时候，如果你有另一台相同版本MySQL服务器上的同结构表，可以把它的.frm文件复制过来；或者，如果你清楚地记得表结构，可以先DROP掉坏表，然后根据记忆重新CREATE一个一模一样的空表，MySQL会自动生成新的.frm文件，然后再用myisamchk等工具修复数据。

不得不提的是,现在更推荐使用InnoDB存储引擎，与MyISAM相比，InnoDB天生就拥有更强的崩溃恢复能力，在大多数意外关机的情况下，InnoDB引擎在下次启动时能够通过日志自动回滚未完成的事务、重做已提交的事务，从而最大程度保证数据的一致性和完整性，很大程度上避免了表损坏的问题。（这个优势在Percona等数据库技术博客中被广泛讨论和推荐）

遇到表损坏千万别慌,备份先行，先易后难”的原则：先从简单的mysqlcheck和REPAIR TABLE尝试，不行再使用需要停机的myisamchk，平时做好定期备份，并考虑将表引擎迁移到更健壮的InnoDB，这样才能防患于未然，让你高枕无忧。