什么导致了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的损坏可能由多种因素导致。以可能性从大到小排序,它们依次为:

  1. 由于服务器崩溃,意外关闭,或硬件错误引起的损坏
  • 如果在写的过程中,mysqld进程被杀掉或崩溃可能会导致损坏。
  • 由于电源故障导致运行MySQL的服务器关闭可能会导致损坏。
  • 还可能由于硬件错误导致,如服务器的硬盘问题,这比之前的问题引起损坏的可能性低。
  • RAM中的损坏;重启硬件可能解决这个罕见的问题;如果在操作系统缓存中有损坏的数据,有时只需重启,不需要通断电就能解决这个问题。这个情况比较罕见,但如果你的硬件故障,发生频率就会很高。

服务器重启时的自动修复通常会解决这个问题,但有时需要使用REPAIR TABLE SQL 语句以及更深入的检查选项。当你的表很大,而服务器离线并有强制更快修复的选项时,可以使用myisamchk 。如果你有许多CPU 内核且表中有许多索引,你应该尝试myisamchk 选项先来使用多个线程,因为这通常会更快;这个选项失败时而会有报告,所以不太可能尝试后发现只需要单个线程。

 

  1. 由于其他程序导致的损坏
  • 如果你在使用外部程序,如myisamchk,这会在服务器运行时对表进行更改,你就很可能遇到损坏。
  • 部分或反病毒软件也经常导致损坏,有时由于恢复表的旧版,或由于检验需要的文件。

这些情况的第一步是找出是什么更改了文件。修复表只是暂时的方法。

  1. 由于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

*

沪ICP备14014813号-2

沪公网安备 31010802001379号