table_open_cache太大引发的问题

一直以来，有个产品，经常性的连接不上，后通过lsof 发现有很多连接符，到数据库中查看

mysql>show global status like '%open%file%';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Open_files    | 1276   |
| Opened_files  | 355689 |
+---------------+--------+
2 rows in set (0.00 sec)

后把open_files_limit 改为10240，且通过ulimit -n 把系统的连接数也改成10240

| open_files_limit          | 10240                             |

但是修改后，Open_files  还是经常性的持续增加，有时候都能达到10100左右，最后就是客户端连接不上，用户抱怨，

仔细分析：这个产品有好10个表用的是mysql 5.1 partition，分为50个分区，这样在假设最低连接数为10，每个连接只打开一个表

那么最低也需要10*3*10*2（MYD+MYI）=6000个文件描述符，这样随着连接的增加，连接符越来越多，如果超过系统设定的连接数，那么最终就会导致客户端连接不上的效果。

后想到mysql里，有两个参数是与文件描述符有关系，一个是上面设置的open_files_limit，另一个就是我要说的table_open_cache；

文档上说，增加table_open_cache，会增加文件描述符，当把table_open_cache设置为很大时，如果系统处理不了那么多文件描述符，那么就会出现客户端失效，连接不上，引用文档上的一句话：

If table_open_cache is set too high, MySQL may run out of file descriptors and refuse connections, fail to perform queries, and be very unreliable. 

如果我们把table_open_cache设置小一点，那么mysql会随着table cache的不足，而关闭不用或者少用的表的cache，这样会释放文件描述符，最终，总的连接数就降下来了，就不会出现lsof 看到N多连接的情况了。

开始时，table_open_cache设置为2048，后把他直接改为默认64，终于解决这个让同事不爽问题了！（^-^设置这么小，有点过于激进了）