解决mysql表被crash的一次维护始末
有客户反馈ＢＯＳＳ系统无法查询到6月28日以后的话单纪录，查询数据库后发现在执行对原始话单表执行查询时候偶尔出现
Table '*****' is marked as crashed and should be repaired.
确定计费无误后决定在下班后执行对表的修复工作，因为以前没有进行过此类操作，担心会有问题，看到baidu出的资料提示修复后要重启mysql服务．
于是在下班后完全备份了数据库，执行了数据表修复，修复方法如下：
shell> myisamchk -r [tablename];
看到执行修复操作成功，于是restart mysql ,考虑到以前的mysql重启和其他服务的冲突，运维纪录是要重启server的，于是reboot 了
等再连上后发现数据库在localhost域上是可以登陆的，其他域上无法连接，连接报1006１错误．重启mysql服务，无效
没有办法，恢复到备份前的状态，可以访问了，但前一个阶段修复的表不见了，查数据库物理文件是存在的，没有办法，吓坏了我
只好死马当活马医，再次执行了表修复，这次没有急着重启了mysql，发现表出来了，执行查询也正常了，一切ＯＫ
看来重启服务不是必须的，至少这次是这样．幸好次几操作都有备份！
但困惑的是第一次执行了修复后重启怎么就连不上server了呢＞
好了，也不明白为什么表会被crash掉，将白皮书上的资料贴下来供参考：
1、错误产生原因，有网友说是频繁查询和更新表造成的索引错误，还有说法为是MYSQL数据库因为某种原因而受到了损坏，如数据库服务器突发性的断电、在提在数据库表提供服务时对表的原文件进行某种操作都有可能导致MYSQL数据库表被损坏而无法读取数据。总之就是因为某些不可测的问题造成表的损坏。
２、myisamchk工具介绍（见mysql的官方手册）
可以使用myisamchk实用程序来获得有关数据库表的信息或检查、修复、优化他们。myisamchk适用MyISAM表(对应.MYI和.MYD文件的表)。
调用myisamchk的方法：
options指定你想让myisamchk做什么。在后面描述它们。还可以通过调用myisamchk --help得到选项列表。
tbl_name是你想要检查或修复的数据库表。如果你不在数据库目录的某处运行myisamchk，你必须指定数据库目录的路径，因为myisamchk不知道你的数据库位于哪儿。实际上，myisamchk不在乎你正在操作的文件是否位于一个数据库目录；你可以将对应于数据库表的文件拷贝到别处并且在那里执行恢复操作。
如果你愿意，可以用myisamchk命令行命名几个表。还可以通过命名索引文件(用“ .MYI”后缀)来指定一个表。它允许你通过使用模式“*.MYI”指定在一个目录所有的表。例如，如果你在数据库目录，可以这样在目录下检查所有的MyISAM表：
如果你不在数据库目录下，可通过指定到目录的路径检查所有在那里的表：
你甚至可以通过为MySQL数据目录的路径指定一个通配符来检查所有的数据库中的所有表：
shell> myisamchk /path/to/datadir/*/*.MYI
推荐的快速检查所有MyISAM表的方式是：
shell> myisamchk --silent --fast /path/to/datadir/*/*.MYI
如果你想要检查所有MyISAM表并修复任何破坏的表，可以使用下面的命令：
-O key_buffer=64M -O sort_buffer=64M \
-O read_buffer=1M -O write_buffer=1M \
/path/to/datadir/*/*.MYI
该命令假定你有大于64MB的自由内存。关于用myisamchk分配内存的详细信息，参见5.9.5.5节，“myisamchk内存使用”。
当你运行myisamchk时，必须确保其它程序不使用表。否则，当你运行myisamchk时，会显示下面的错误消息：
warning: clients are using or haven't closed the table properly
这说明你正尝试检查正被另一个还没有关闭文件或已经终止而没有正确地关闭文件的程序(例如mysqld服务器)更新的表。
如果mysqld正在运行，你必须通过FLUSH TABLES强制清空仍然在内存中的任何表修改。当你运行myisamchk时，必须确保其它程序不使用表。避免该问题的最容易的方法是使用CHECK TABLE而不用myisamchk来检查表。
