应用于:
MySQL 服务器-版本：4.0 到 5.5 –发行版：到5.5
MySQL 服务器-版本：4.0 以上–发行版：4.0 以上
MySQL 服务器-版本：4.0 到 5.5 –发行版：4.0 到 5.5
所有平台
目标
说明MyISAM 表损坏的具体原因
解决方案
MyISAM 存储引擎非常可靠。但如果时常遇到MyISAM 表损坏，你最好思考导致这个问题的原因。在查询数据时，以下错误信息通常意味着表损坏：
Error 1034 Incorrect key file for table: ‘…’. Try to repair it
或包含以下错误号码之一的信息：
Error 126 = Index file is crashed
Error 127 = Record-file is crashed
Error 134 = Record was already deleted (or record file crashed)
Error 144 / Error 1195 = Table is crashed and last repair failed
Error 145 / Error 1194 = Table was marked as crashed and should be repaired
当查询本该查找到在表中的行但没有找到，或当一个查询返回不完整的数据，也可以假定发生了损坏。你可以使用CHECK TABLE 语句来验证MyISAM 表是否损坏。
MyISAM的损坏可能由多种因素导致。以可能性从大到小排序，它们依次为：
- 由于服务器崩溃，意外关闭，或硬件错误引起的损坏
- 如果在写的过程中，mysqld进程被杀掉或崩溃可能会导致损坏。
- 由于电源故障导致运行MySQL的服务器关闭可能会导致损坏。
- 还可能由于硬件错误导致，如服务器的硬盘问题，这比之前的问题引起损坏的可能性低。
- RAM中的损坏；重启硬件可能解决这个罕见的问题；如果在操作系统缓存中有损坏的数据，有时只需重启，不需要通断电就能解决这个问题。这个情况比较罕见，但如果你的硬件故障，发生频率就会很高。
服务器重启时的自动修复通常会解决这个问题，但有时需要使用REPAIR TABLE SQL 语句以及更深入的检查选项。当你的表很大，而服务器离线并有强制更快修复的选项时，可以使用myisamchk 。如果你有许多CPU 内核且表中有许多索引，你应该尝试myisamchk 选项先来使用多个线程，因为这通常会更快；这个选项失败时而会有报告，所以不太可能尝试后发现只需要单个线程。
- 由于其他程序导致的损坏
- 如果你在使用外部程序，如myisamchk，这会在服务器运行时对表进行更改，你就很可能遇到损坏。
- 部分或反病毒软件也经常导致损坏，有时由于恢复表的旧版，或由于检验需要的文件。
这些情况的第一步是找出是什么更改了文件。修复表只是暂时的方法。
- 由于bug导致的损坏
- 使用在2007年夏季之前版本的服务器建设。从2006年开始到2007年，MySQL执行了系统的测试来找出罕见且难以复制的MyISAM损坏bug。大约在2007年夏季，我们看到几乎所有bug相关的损坏问题来自旧版本，有广泛修复的较新版本很少受到影响。你能通过将版本升级到接近于2007夏季的版本，最好是最接近的，来消除遇到损坏的可能性，越接近的版本越好。
- 如果bug仍导致损坏，你应该首先查看最近引入的服务器功能和情况，其中并发级别很高的区域是最可能有问题的。现今，新的损坏bug通常涉及具体客户的语句结合和高并发性，或新功能和高并发性。
你能查找在错误认知中最近重启的mysqld 来验证表是否由于服务器崩溃而损坏。如果没有错误信息表明问题是由于服务器故障，且损坏看上去发生在正常操作期间，这可能是bug。因此，你应该尝试创建一个可复制的测试以反映出问题并通过在My Oracle Support中开启一个Support Request 来报告问题。
再说一次，你能用REPAIR TABLE SQL 语句来修改损坏的MyISAM表。此外，当 mysqld不在运行时，你能用myisamchk 命令来检查或修复表。
Comment