自从前几天以来，我们在安装MySQL时遇到了一些严重的问题：MySQL不断打开临时文件（正常行为），但是这些文件永远不会被释放。 结果是，最终，磁盘空间耗尽，我们必须重新启动服务并手动清理/ tmp。
使用lsof，我们看到这样的东西：
mysqld 16866 mysql 5u REG 8,3 0 692 /tmp/ibyWJylQ (deleted) mysqld 16866 mysql 6u REG 8,3 0 707 /tmp/ibf5adsT (deleted) mysqld 16866 mysql 7u REG 8,3 0 728 /tmp/ibGjPRyW (deleted) mysqld 16866 mysql 8u REG 8,3 0 5678 /tmp/ibMQDLMZ (deleted) mysqld 16866 mysql 13u REG 8,3 0 5679 /tmp/ibQAnM42 (deleted) 也许这不是相关的，但是当我们closures服务器时，文件终于被释放了，我们可以在MySQL日志中看到以下警告：
121029 7:44:27 [Warning] /usr/local/mysql/bin/mysqld: Forcing close of thread 1333 user: 'xxx' 121029 7:44:27 [Warning] /usr/local/mysql/bin/mysqld: Forcing close of thread 1156 user: 'yyy' 121029 7:44:27 [Warning] /usr/local/mysql/bin/mysqld: Forcing close of thread 1151 user: 'zzz'
其中'xxx'，'yyy'和'zzz'是不同的mysql用户（以及只有3个有活动连接数据库的用户）。
我们有几个理论：
在操作系统中有一个问题，它保持文件处理程序打开。 操作系统“删除”可能会阻塞线程，直到关机？ 这可以解释关机时的警告以及文件在进程死亡时最终被删除的事实。
到目前为止，数据集非常小，临时文件相对较小，并且没有足够的时间释放文件句柄而不耗尽磁盘空间。
我们在默认内核的RHEL 6.2上使用Mysql 5.5。
那么…这不是一个真正的解决scheme，但我认为这是研究的结束。
这似乎是MySQL中的一个错误。 我们通过这个bug发现它似乎是这个的重复
作为解决方法，为了避免产生如此多的临时文件，我们增加了binlog_cache_size为我们合理的一个值（在对应用程序进行基准testing后，用lsof检查文件的大小）。 如果你想探索更多，你可以find一个关于其他选项来解决这个问题的文章 。
希望它可以帮助别人;）
作为参考，还有一个非常类似的bug： http : //bugs.mysql.com/bug.php?id=66237 。 而这个似乎在5.5中不是固定的。