mysql单表损坏原因_什么导致了MySQL服务器中的MyISAM 表损坏？

应用于:

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 命令来检查或修复表。