MySQL表索引为什么会遭破坏?

数据库 MySQL
的文章主要是介绍一种更为快捷的方法来实现MySQL表索引被破坏的问题,下面就是对其具体方案的描述,希望在你今后的学习中会有所帮助。

此文章主要向大家描述的是MySQL表索引被破坏的问题的产生缘由,以及针对这一问题我们给出其具体的解决方案,下面的文章就是对其相关内容的具体介绍,希望在你今后的学习中会有所帮助。

下午上班,惊闻我的dedecms的网站出问题了,访问一看,果然全屏报错,检查MySQL(和PHP搭配之***组合)日志,错误信息为:

 

 

  1. Table '.\dedecmsv4\dede_archives' is marked as crashed and should be repaired 

提示说cms的文章表dede_archives被标记有问题,需要修复。于是赶快恢复历史数据,上网查找原因。最终将问题解决。解决方法如下:

找到MySQL(和PHP搭配之***组合)的安装目录的bin/myisamchk工具,在命令行中输入:

 

  1. myisamchk -c -r ../data/dedecmsv4/dede_archives.MYI 

然后myisamchk 工具会帮助你恢复数据表的索引。重新启动MySQL(和PHP搭配之***组合),问题解决。

MySQL表索引被破坏的问题分析:

1、MySQL表索引被破坏的错误产生原因

有网友说是频繁查询和更新dede_archives表造成的索引错误,因为我的页面没有静态生成,而是动态页面,因此比较同意这种说法。还有说法为是MySQL(和PHP搭配之***组合)数据库因为某种原因而受到了损坏,如:数据库服务器突发性的断电、在提在数据库表提供服务时对表的原文件进行某种操作都有可能导致MySQL(和PHP搭配之***组合)数据库表被损坏而无法读取数据。总之就是因为某些不可测的问题造成表的损坏。

问题的编号为145

2、问题解决办法。

当你试图修复一个被破坏的表的问题时,有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立,删除信息所指出的文件并再试一次--这通常是上一次修复操作遗留下来的。

这三种修复方法如下所示:

 

 

  1. % myisamchk --recover --quick /path/to/tblName   
  2. % myisamchk --recover /path/to/tblName   
  3. % myisamchk --safe-recover /path/to/tblName  

 

 

 

***种是最快的,用来修复最普通的问题;而***一种是最慢的,用来修复一些其它方法所不能修复的问题。

 

检查和修复MySQL(和PHP搭配之***组合)数据文件

如果上面的方法无法修复一个被损坏的表,在你放弃之前,你还可以试试下面这两个技巧:

 

如果你怀疑表的索引文件(*.MYI)发生了不可修复的错误,甚至是丢失了这个文件,你可以使用数据文件(*.MYD)和数据格式文件(*.frm)重新生成它。首先制作一个数据文件(tblName.MYD)的拷贝。重启你的MySQL(和PHP搭配之***组合)服务并连接到这个服务上,使用下面的命令删除表的内容:

 

MySQL(和PHP搭配之***组合)> DELETE FROM tblName;

 

在删除表的内容的同时,会建立一个新的索引文件。退出登录并重新关闭服务,然后用你刚才保存的数据文件(tblName.MYD)覆盖新的(空)数据文件。***,使用myisamchk执行标准的修复(上面的第二种方法),根据表的数据的内容和表的格式文件重新生成索引数据。

 

如果你的表的格式文件(tblName.frm)丢失了或者是发生了不可修复的错误,但是你清楚如何使用相应的CREATE TABLE语句来重新生成这张表,你可以重新生成一个新的.frm文件并和你的数据文件和索引文件(如果索引文件有问题,使用上面的方法重建一个新的)一起使用。首先制作一个数据和索引文件的拷贝,然后删除原来的文件(删除数据目录下有关这个表的所有记录)。

启动MySQL(和PHP搭配之***组合)服务并使用当初的CREATE TABLE文件建立一个新的表。新的.frm文件应该可以正常工作了,但是***你还是执行一下标准的修复(上面的第二种方法)。

 

3、MySQL表索引被破坏解决,myisamchk工具介绍(见MySQL(和PHP搭配之***组合)的官方手册)

 

可以使用myisamchk实用程序来获得有关数据库表的信息或检查、修复、优化他们。myisamchk适用MyISAM表(对应.MYI和.MYD文件的表)。

调用myisamchk的方法:

 

  1. shell> myisamchk [options] tbl_name ... 

options指定你想让myisamchk做什么。在后面描述它们。还可以通过调用myisamchk --help得到选项列表。

 

tbl_name是你想要检查或修复的数据库表。如果你不在数据库目录的某处运行myisamchk,你必须指定数据库目录的路径,因为myisamchk不知道你的数据库位于哪儿。实际上,myisamchk不在乎你正在操作的文件是否位于一个数据库目录;你可以将对应于数据库表的文件拷贝到别处并且在那里执行恢复操作。

如果你愿意,可以用myisamchk命令行命名几个表。还可以通过命名索引文件(用“ .MYI”后缀)来指定一个表。它允许你通过使用模式“*.MYI”指定在一个目录所有的表。例如,如果你在数据库目录,可以这样在目录下检查所有的MyISAM表:

 

  1. shell> myisamchk *.MYI 

如果你不在数据库目录下,可通过指定到目录的路径检查所有在那里的表:

 

 

  1. shell> myisamchk /path/to/database_dir/*.MYI 

你甚至可以通过为MySQL(和PHP搭配之***组合)数据目录的路径指定一个通配符来检查所有的数据库中的所有表:

 

 

  1. shell> myisamchk /path/to/datadir/*/*.MYI 

推荐的快速检查所有MyISAM表的方式是:

 

 

  1. shell> myisamchk --silent --fast /path/to/datadir/*/*.MYI 

如果你想要检查所有MyISAM表并修复任何破坏的表,可以使用下面的命令:

 

 

  1. shell> myisamchk --silent --force --fast --update-state \  
  2. -O key_buffer=64M -O sort_buffer=64M \  
  3. -O read_buffer=1M -O write_buffer=1M \  
  4. /path/to/datadir/*/*.MYI 

 

 

该命令假定你有大于64MB的自由内存。关于用myisamchk分配内存的详细信息,参见5.9.5.5节,“myisamchk内存使用”。

 

当你运行myisamchk时,必须确保其它程序不使用表。否则,当你运行myisamchk时,会显示下面的错误消息:

 

  1. warning: clients are using or haven't closed the table properly 

这说明你正尝试检查正被另一个还没有关闭文件或已经终止而没有正确地关闭文件的程序(例如MySQL(和PHP搭配之***组合)d服务器)更新的表。

 

如果MySQL(和PHP搭配之***组合)d正在运行,你必须通过FLUSH TABLES强制清空仍然在内存中的任何表修改。当你运行myisamchk时,必须确保其它程序不使用表。避免该问题的最容易的方法是使用CHECK TABLE而不用myisamchk来检查表。

 

以上的相关内容就是对MySQL表索引被破坏的问题及解决的介绍,望你能有所收获。

【编辑推荐】

  1. MySQL数据库与表的几个基本命令示例
  2. MySQL EMS的乱码问题的歼灭
  3. MySQL表索引遭到破坏的处理方法
  4. 开源携手MySQL数据库的发展前景
  5. MySQL root 密码忘记的破解
责任编辑:佚名 来源: 互联网
相关推荐

2020-12-11 08:02:16

索引MySQL存储

2020-11-27 06:58:24

索引

2010-06-10 14:14:18

个MySQL表索引

2022-04-16 14:20:29

MySQL数据库

2020-10-16 17:20:21

索引MySQL数据库

2010-11-24 14:03:28

mysql表索引

2022-05-18 08:25:59

MySQLutf8字符集数据库

2022-03-02 10:11:41

索引场景数据库

2016-12-02 16:09:52

数据中心灾难恢复

2014-01-22 09:54:09

网络布线数据中心

2021-02-03 08:52:52

Mysql索引数据库

2021-10-25 08:49:32

索引数据库MySQL

2024-06-12 09:16:23

2022-03-28 08:24:52

MySQL聚簇索引非聚簇索引

2023-09-20 14:54:17

MySQL

2022-06-27 07:23:44

MySQL常量优化

2021-07-09 09:24:06

NanoID UUID软件开发

2020-03-30 15:05:46

Kafka消息数据

2012-08-17 10:01:07

云计算

2012-03-26 10:26:43

openstackeucalyptus
点赞
收藏

51CTO技术栈公众号