老实说，MYSQL已经用了两年多了，版本也升到4.1.7。
反而觉得系统有些不稳定。记得还是几个月前，电话说服务器上的数据文件损坏，这让我很纳闷，因为一直以来都没出过问题。于是，就想到修复的想法。直接在phpmyadmin执行repair table table_name的命令（这是老大告诉我的捷径，不过听说他7月要去南非了，有点怅然，不知道工作组的未来如何，有时候也觉得太过依赖他，很多该独当一面的事都没有自己去完成，只是小小感叹一下）。
今天做新闻模块的数据表设计，第一次在自己机器上发生数据文件损坏，小小的吃了一惊。
“由于临时断电，使用kill -9中止MySQL服务进程，或者是mysql正在高速运转时进行强制备份操作时等，所有的这些都可能会毁坏MySQL的数据文件。如果在被干扰时，服务正在改变文件，文件可能会留下错误的或不一致的状态。因为这样的毁坏有时是不容易被发现的，当你发现这个错误时可能是很久以后的事了。于是，当你发现这个问题时，也许所有的备份都有同样的错误。”
这是网上给我的解释。
每一个数据表对应三个文件，它们和表名相同，但是具有不同的扩展名。table_name.frm文件是表的定义，它保存了表中包含的数据列的内容和类型。table_name.MYD文件包含了表中的数据。table_name.MYI文件包含了表的索引(例如，它可能包含lookup表以帮助提高对表的主键列的查询)。基本上出问题的经常是MYI文件。（比如今天）
要检查一个表的错误，只需要运行myisamchk(在MySQL的bin目录下)并提供文件的位置和表名，或者是表的索引文件名：
% myisamchk /usr/local/mysql/var/dbName/tblName
% myisamchk /usr/local/mysql/var/dbName/tblName.MYI
上面的两个命令都可以执行对指定表的检查。要检查数据库中所有的表，可以使用通配符：
% myisamchk /usr/local/mysql/var/dbName/*.MYI
要检查所有数据库中的所有表，可以使用两个通配符：
% myisamchk /usr/local/mysql/var/*/*.MYI
如果不带任何选项，myisamchk将对表文件执行普通的检查。如果你对一个表有怀疑，但是普通的检查不能发现任何错误，你可以执行更彻底的检查(但是也更慢！)，这需要使用–extend-check选项：
% myisamchk –extend-check /path/to/tblName
对错误的检查是没有破坏性的，这意味着你不必担心执行对你的数据文件的检查会使已经存在的问题变得更糟。另一方面，修复选项，虽然通常也是安全的，但是它对你的数据文件的更改是无法撤消的。因为这个原因，我们强烈推荐你试图修复一个被破坏的表文件时首先做个备份，并确保在制作这个备份之前你的MySQL服务是关闭的。
c:\program files\mysql\bin>myisamchk
可以看到error report关于mambo\mos_session.MYI
c:\program files\mysql\bin>myisamchk –recover –quick c:\program files\mysql\data\mambo\mos_session.myi
系统提示：–safe-recover(-o) or the –force(-f) option进行修复操作
c:\program files\mysql\bin>myisamchk –safe-recover c:\program files\data\mambo\mos_session.myi
最后用phpmyadmin访问一下就ok了。
这三种修复方法如下所示：
% myisamchk –recover –quick /path/to/tblName
% myisamchk –recover /path/to/tblName
% myisamchk –safe-recover /path/to/tblName
第一种是最快的，用来修复最普通的问题；而最后一种是最慢的，用来修复一些其它方法所不能修复的问题。