查询日志查看报错原因，发现是MySQL的问题。报错信息如下图：
SQLSTATE[HY000]: General error: 1 Can't create/write to file '/tmp/#sql_361_0.MYI' (Errcode: 28)

image.png

参考文档：Mysql Can't create/write to file '/tmp/#sql_361_0.MYI

查看inode的使用情况

[root@localhost ~]# df -i
Filesystem            Inodes  IUsed   IFree IUse% Mounted on
/dev/mapper/VolGroup-LogVol00
                     1888656 159855 1728801    9% /
tmpfs                 490580      4  490576    1% /dev/shm
/dev/sda1              51200     39   51161    1% /boot 

知道了是inode数量100%造成的问题，接下来就是查看原因并解决掉就好了

image.png

参考文档：linux下清空或删除大文件

6.使用rsync命令

假如你有一些特别大的文件要删除，比如nohup.out这样的实时更新的文件，动辄都是几十个G上百G的，也可以用rsync来清空大文件，而且效率比较高。

1）创建空文件

touch/data/blank.txt

2）用rsync清空文件

rsync -a --delete-before --progress --stats /root/blank.txt /root/nohup.out

快速删除大量文件

假如你要在linux下删除大量文件，比如100万、1000万，像/var/spool/clientmqueue/的mail邮件，/usr/local/nginx/proxy_temp的nginx缓存等，那么rm -rf *可能就不好使了。 rsync 可以用来清空目录或文件，如下：

1）先建立一个空目录# mkdir/data/blank

2）用rsync删除目标目录

rsync -a --delete-before --progress --stats /var/spool/postfix/maildrop/

这样目标目录很快就被清空了

注：其中--delete-before 接收者在传输之前进行删除操作

为什么rsync能够快速删除大文件？

1）rm命令大量调用了lstat64和unlink，可以推测删除每个文件前都从文件系统中做过一次lstat操作。过程：正式删除工作的第一阶段，需要通过getdirentries64调用，分批读取目录（每次大约为4K），在内存中建立rm的文件列表；第二阶段，lstat64确定所有文件的状态；第三阶段，通过unlink执行实际删除。这三个阶段都有比较多的系统调用和文件系统操作。

2）rsync所做的系统调用很少：没有针对单个文件做lstat和unlink操作。命令执行前期，rsync开启了一片共享内存，通过mmap方式加载目录信息。只做目录同步，不需要针对单个文件做unlink。另外，在其他人的评测里，rm的上下文切换比较多，会造成System CPU占用较多——对于文件系统的操作，简单增加并发数并不总能提升操作速度。 总结：频繁做减法不如直接从头来过把文件系统的目录与书籍的目录做类比，rm删除内容时，将目录的每一个条目逐个删除(unlink)，需要循环重复操作很多次；rsync删除内容时，建立好新的空目录，替换掉老目录，基本没开销。

参考：https://blog.csdn.net/liuxiao723846/article/details/51626305

2022年4月15日11:34:19 使用如下命令慢，但是有效：
find /var/spool/postfix/maildrop/ -type f -exec rm {} \;