起因：分公司的项目由于数据量比较小一直采用MYISAM，搭建好以后就交给分公司的运维工程师维护，众所周知这存储引擎经常会由于表损坏而**，幸运的是mysql提供了在线修复工具，不过建议比较重要的数据还是转换成innodb存储引擎，尤其是并发量更新比较大的时候，本文就会带你领略一次mysql典型的错误！
环境：
网站架构：LNMP（linux+nginx+mysql+php）
系统：Centos 5.5 64bit
Mysql：mysql 5.1.50，MYISAM引擎
详细过程：
晚上回到家正准备吃饭，接到电话，说分公司的论坛登录不了了，说连接不上数据库，让我去看一下，于是通过SecureCRT登录到服务器，首先查看mysql的error日志,查看到的错误日志内容如下：
111121 20:08:40 [ERROR] /usr/local/mysql/libexec/mysqld: Incorrect key file for table './ucentersmutf8/uc_members.MYI'; try to repair it
111121 20:08:40 [ERROR] Got error 126 when reading table './ucentersmutf8/uc_members'
很明显是由于ucentersmutf8数据库的uc_members表损坏造成的，找到问题就好解决了，于是通过mysql –uroot –p ******登录到服务器，奇怪发现登录不了，ps aux | grep mysqld查看，发现有人在重启mysqld，打电话至分部那边确认，果然，他们发现网站访问的时候报数据库错误，就想当然的去重启mysqld，而不分析是什么原因导致的。当他们重启的时候发现mysql直接一直等待，所以给我打电话。由于不确定需要等待多上时间，我直接通过命令ps aux | grep mysqdd找到mysqld的进程id，直接kill -9结束掉。然后执行/etc/rc.d/init.d/mysqld start启动，发现启动失败，再查看mysql的错误日志，发现了如下报错：
111121 20:22:59 [ERROR] MYSQL_BIN_LOG::open_purge_index_file failed to open register file.
111121 20:22:59 [ERROR] MYSQL_BIN_LOG::open_index_file failed to sync the index file.
111121 20:22:59 [ERROR] Aborting
Mysql找不到二进制日志索引文件？cd到mysql的数据目录发现mysql-bin.index存在，突然看到目录下面所有的文件的属主都变成了www，晕倒，谁把mysql数据库目录有的权限给改了？？？ 于是执行chown –R mysql.mysql /data/dbdata，然后/etc/rc.d/init.d/mysqld start，OK。启动没问题了，接下来就是修复mysql的表了，修复过程如下：
mysql –uroot –p***** #登录到mysql
use ucentersmutf8; #进入指定的数据库
check table uc_members #查看表是否损坏
repair table uc_members #修复uc_members表
修复完成之后访问网站，一切OK！后来询问分部那边，原来是mysql的数据目录和网站的目录在同一总目录下，那个管理员网站文件的时候图方便，直接用chown –R /data把/data目录下所有的文件都更改成www用户了。看来有必要加一个监控所有表的状态的脚本来实时报警了！