前些天说了一下如何修复损坏的MyISAM表，可惜只会修复并不能脱离被动的境地，只有查明了故障原因才会一劳永逸。
如果数据库服务非正常关闭（比如说进程被杀，服务器断电等等），并且此时恰好正在更新MyISAM表，那么发生损坏的概率就比较大。今天我要说的是另一种情况：频繁的打开关闭MyISAM表文件造成MyISAM表损坏。
什么时候会出现频繁的打开关闭MyISAM表文件的情况呢？
先查看当前系统的table_cache设置，它的作用就是缓存表文件描述符，降低打开关闭表的频率，如果这个参数设置得过小，那么很快就会被占满，再有新请求过来的时候，就不得不关闭一些已打开的表以便为新请求腾出空间，从而出现频繁的打开关闭MyISAM表文件的情况：
mysql> show variables like ‘table%’;
再查看当前系统的打开表的情况：
mysql> show status like ‘open%’;
有两项关键的结果：Open_tables和Opened_tables，他们的名字类似，其含义的区别在于：
Open_tables：表示当前打开的表数目。
Opened_tables：表示累计已经打开的表数目。
那么如何判断table_cache是否设置合理呢？其判断尺度如下：
如果Opened_tables远大于Open_tables，并且Open_tables很接近table_cache，那么就说明table_cache偏小。
还要注意设置操作系统的参数，因为即便你把table_cache设置得很大，一旦超过了操作系统的限制也没用，可以按如下方法查询当前值：
ulimit -a | grep “open”
设置方法也很简单，比如设置成8k，可以这样：
ulimit -n 8192
最好把此命令添加到/etc/rc.local或者/etc/profile之类的文件里，使之在MySQL启动前生效。
MySQL运行稳定后，查看open_files_limit参数：
mysql> show variables like ‘%open%’;
在大量使用MyISAM的环境里，应该保证open_files_limit表类型至少是table_cache的三倍，这是因为每个MyISAM表都包括三个文件：一个表定义文件，一个表索引文件，一个表数据文件，而在Innodb的环境里，一个表只有一个文件，明白这些基本知识对解决问题很有帮助。
如果太低的话最好在my.cnf里设定open_files_limit。
为了保险点，或许还要查查内核的相关参数，比如fs.file-max，这些细节往往会影响到MySQL：
sysctl -a | grep “file”
注意到以上这些因素，问题差不多就能解决了。
BTW：如果你比较懒惰，也可以用MySQL Performance Tuning Primer Script来判断参数是否合理