- 问题背景
生产环境的mysql 报 too many open files 异常。如下图所示
- 分析过程
- 看到报too many open files， 第一时间想到的就是系统文件句柄和mysql 打开文件数设置过低导致的，因此。这里首先查看系统文件句柄数以及mysql 打开文件数的相关参数。
这里系统配置的文件句柄是6万多，mysql 配置的打开文件数也是6万多。一般情况下，应该是够用的才对。
- 我们知道了系统和mysql文件句柄数的配置，接着。我们看下mysql 当前打开的文件数。
从这里可以看出，当前打开的文件数是4.5万。 从这里可以看出，很大概率上，打开的表是myisam引擎的。而且表中存在了很多分区。
- 看mysql目前打开文件句柄数较多的表是哪些
这里打开的都是一些统计表。而且是myisam 存储引擎的。每张表存放了一个月的数据。其中有小时分区和按天分区的。对于myisam存储引擎的表。每个会话访问该表时，都会打开该表的所有分区，每一个分区就占用一个文件描述符。。这也是为什么会报too many open files 的原因。
- 解决方案
从上面的分析中，我们知道mysql 报too many open files 的原因了。
由于数据库中有很多统计表，这些表采用的是myisam 存储引擎的。且很多是小时分区的表。这些表保存的时间周期是1个月。这里就会导致每一个会话访问这些统计表时，占用过多的文件描述符。
我们知道了异常的原因，那么就可以给出解决方案了。
1、这里快速的解决方案是修改系统文件句柄数限制以及mysql打开文件数限制。具体如何修改，可以百度。
这里我们可以配置多大合适？ 可以根据mysql 最大的连接数限制乘与当前数据库所有myisam表的分区数。比如如下:
这里最大的连接数是335. 我们假设当前数据库的myisam表分区的总数是10000. 那么我们配置的文件句柄数可以比这个数（3350000）大一点即可。
2、从业务上进行解决。比如是否可以改为innodb 表。这个需要看业务需求（因为这里采用myisam，是有一些原因的，比如都是一些分析用的场景，那么采用myisam确实可以提高查询和写入效率等）。
3、如果不能够改为innodb表，那么看下是否可以进行拆分。比如把小时分区的表，按天进行拆分。因为有时候我们只需要查当天的数据即可。但由于是小时分区的myisam表。这时候会导致其他分区的会占用文件描述符。