- 問題背景
生產環境的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表。這時候會導致其他分區的會佔用文件描述符。