我们有两个Ubuntu 8.04服务器。 在数据库服务器中，我将table_cache设置为1000，但是当我重新启动mysql时，状态只显示257，打开的文件限制是1024
我通过执行ulimit -n 8192来调整ulimit，然后重新启动mysql; 这似乎做了滴答，但几个小时后，我做了ulimit -n，看到它已经回到了1024
一点担心。
我编辑了/etc/security/limits.conf并添加了
mysql soft nofile 8192
mysql hard nofile 8192
然后重新启动，没有改变。 然后，我编辑和更改MySQL *重新启动，没有改变，然后我编辑并将其更改为一行
* - nofile 8192
并重新启动，没有改变。
cat /proc/sys/fs/file-max给了我768730
sysctl fs.file-max给我fs.file-max = 768730
我有点损失，我可以如何设置和保持ulimit值设置，所以我可以在MySQL上正确地增加表caching。
[编辑：为了清晰解释细节]
我怀疑你检查了与mysql不同的用户的ulimit;）
更改limits.conf后不必重新启动。 您必须在/etc/pam.d/相应的PAM服务中启用此文件。
请grep pam_limits /etc/pam.d/*获取线索，在这种情况下limits.conf将被使用。
例如，可以在sudo -u user bash调用的shell中显示limits.conf更改，但在以sudo su - user身份运行时不会显示，这是因为在Ubuntu上，默认设置如下所示：
$ grep limits /etc/pam.d/*|grep su
/etc/pam.d/su:# session required pam_limits.so
/etc/pam.d/sudo:session required pam_limits.so
所以，如果你使用sudo su - mysql来检查限制，那么就会出现一个乱码 – su没有打开限制。 您可以通过观看/var/log/auth.log来检查正在运行哪个pam服务。
对于所有可能的types的调用你的mysql，应该是安全的修改pam.d/other或者只是pam.d/common-session 。
一个更直接的方法（还有一个破解）就是在mysql /etc/init.d/mysql的init脚本中添加ulimit -n 8192命令。 该控件对于打开的shell和subprocess/ shell是有效的。
编辑： su和sudo '古怪'是因为limits.conf文件是有关PAM的限制，如果我没有记错，只适用于loginshell。 此外，还有一些关于start-stop-daemon无法使用pam限制的信息。
如果您不确定MySQL的当前限制，请使用您select的方法（顶部，ps aux，pgrep，无论）检查当前mysqld的进程ID。 然后input
sudo cat /proc/mysql_process_id_you_found/limits
如果它没有告诉你8192打开的文件，你总是可以像某人build议的那样绕过init脚本。
您是否将会话所需的pam_limits.so添加到/etc/pam.d/common-session？