MySQL运行时根磁盘被占满，重启后空间恢复，寻求原因排查方向

嘿，这个情况我之前帮不少人排查过，大概率是MySQL进程攥着已删除文件的句柄（Linux里文件被删除但进程没释放句柄的话，磁盘空间不会真正释放，直到进程关闭），或是临时文件写到了根盘却没自动清理。给你几个具体的排查方向，记得在根盘满的时候（别着急重启）一步步来：

• 先揪出MySQL进程持有的已删除文件：执行 lsof -p $(pidof mysqld) | grep deleted，这个命令会列出MySQL进程还在占用的、已经被删除的文件。如果看到根盘路径下的大文件，那就是元凶——比如之前手动删了旧的日志/binlog文件，但没让MySQL刷新句柄，进程一直抱着这些文件不放，重启后才释放空间。
• 检查MySQL临时文件的存储位置：打开你的my.cnf（或my.ini）看看tmpdir参数，确认它指向的是非根盘的目录（比如你可以把它改成/var/log/mysql下的tmp目录，或者其他有空的磁盘）。如果临时表因为内存不足要写到磁盘时，默认可能会用系统临时目录，但如果你的系统tmp是tmpfs（像你这里的/tmp是tmpfs，空间不大），有没有可能MySQL因为权限问题 fallback 到根盘的某个临时目录？
• 核对所有日志的配置路径：确认错误日志、慢查询日志、通用日志的路径都在你指定的/var/log/mysql（这个盘只用了4%，肯定没问题），有没有可能之前日志配置在根盘的/var/log下，后来改了配置但没重启MySQL，导致进程还在往旧的日志文件写，而旧文件可能已经被你删除了，但句柄还在MySQL手里？
• 检查二进制日志（binlog）的存储：binlog默认在数据目录（你这里是/var/lib/mysql，在xvdc盘），但如果之前配置错了写到根盘，后来改了但没重启，进程还在写旧的binlog文件？另外，别直接用rm删binlog，要用PURGE BINARY LOGS命令，不然进程会一直持有已删除文件的句柄。
• 最后排查表空间文件：虽然你数据在其他盘，但有没有可能误删了根盘上的某个InnoDB表空间文件？这种情况也会导致进程占着空间不释放，重启后才会清理。

按照这些步骤查，应该能快速定位问题～

备注：内容来源于stack exchange，提问作者Mark Walker