我刚刚从 MySQL Jessie 5.5 升级到 MySQL Oracle Community Edition v5.6。
我有一个特定的 MySQL 服务器，它有大约 230 个数据库和 > 32k 个文件/表。
虽然两三年来我从来没有显Debian版本的问题，本次升级后几个小时后该服务器提供的服务失败。
调试问题后，我发现这是由于每个进程打开文件的限制造成的。
我解决了提高每个进程打开文件限制的问题。我添加到/etc/sysctl.conf：
fs.file-max=100000
并/etc/security/limits.conf
* - nofile 100000
后来我重新启动MySQL，服务就恢复正常了。对于讨论此问题的文档。http://duntuk.com/how-raise-ulimit-open-files-and-mysql-openfileslimit
从我自己的服务器：
mysql> show global variables like 'open%';
+------------------+--------+
| Variable_name | Value |
+------------------+--------+
| open_files_limit | 100000 |
+------------------+--------+
1 row in set (0.00 sec)
mysql> select @@table_open_cache;
+--------------------+
| @@table_open_cache |
+--------------------+
| 15000 |
+--------------------+
1 row in set (0.00 sec)
解决问题后我开始寻找脚本或代码是否有任何差异Debian 和 Oracle 版本之间。
在我的简短分析中，我了解到它们在 my.cnf 中都有open_files_limit，在脚本中也有选项“--open-files-limit” /usr/bin/mysqld_safe，这实际上让我找到了我之前提到的文档/链接。
但是，我没有在代码或脚本中找到任何更多信息来证明有关打开文件限制的行为差异是合理的。
我还可以看到，在 Jessie 的另一台使用 MySQL 5.5 的服务器中，table_open_cache 实际上较低。
mysql> select @@table_open_cache;
+--------------------+
| @@table_open_cache |
+--------------------+
| 512 |
+--------------------+
1 row in set (0.00 sec)
虽然默认的 table_open_cache 增加可以部分解释这个问题，但我不确定它是否完全合理。
有人可以解释一下吗？
答案1
该服务器是一台使用较少的旧服务器，因此有如此多的数据库/表。
简而言之，从 5.5 MySQL Debian Jessie 官方包升级到 5.6 MySQL Oracle 版本提高了表缓存的打开文件限制。
虽然 5.5 中打开的表缓存默认为 512 个文件，但在 5.6 中似乎至少为 2048 个文件。
显然，只有当您的表数量超过 1000 个且已经使用/打开的表时，问题才会显现出来，因为非 root 用户打开的文件的每个进程的限制默认为 1024。
提高限制后，缓存似乎正在将自身调整为允许用户打开的文件的 10% 左右，将进一步调查。
最后的评论是，提高系统限制或调整open_files_limitmy.cnf 中的变量或作为 MySQL 的参数可以解决问题。
提高系统限制的另一种方法/etc/security/limits.conf是在 的 mysqld 部分中添加 /etc/mysql/my.cnf
open_files_limit = 100000
应该适当注意的是，对于拥有大量表/虚拟主机/电子邮件用户的数据库、Web 或电子邮件服务器，建议提高打开文件限制。
数据库响应速度似乎也更快（因为更多的表保持打开状态），但是在我的特定情况下，我没有在两个版本之间进行任何比较性能测试。