同事连接数据库，查询数据报错了，Can't create/write to file '/tmp/#sql_89b_0.MYI'  (Errcode: 177 - File exists)：

 

 

而且我自己去连接，正常：

 

我让他关闭客户端连接，再重新执行查询语句，也是报一样的错误。

 

 

 

（1）      去mysql的error日志里面，没有看到异常信息；

 

（2）      在mysql的slow慢查询sql里面，也没有看到异常信息；

 

（3）      Mysql所在的服务器的负载也不高，很低；

 

（4）      Show full processlist; 也没有看到正在卡住的sql记录；

 

（5）      show engine innodb status\G也没有看到死锁或者其他异常信息；

 

 

那么问题在哪里呢？去看下报错的原始文件吧

 

 

[root@zt_dbm1_13_11 ~]# ll /tmp/

 

total 4204

 

-rw-rw-r--. 1 zabbix zabbix      22 Aug 4 16:31 cu.txt

 

-rw-r--r--. 1 root   root     1469 May 18 15:59 localhost-mysql_cacti_stats.txt:3317

 

-rw-rw-r--. 1 zabbix zabbix 4283869Aug  4 16:32 -mysql_cacti_stats.txt:3317

 

-rw-r--r-- 1 root   root       101 Jul 28 15:06 percona-version-check

 

-rw-rw---- 1 mysql  mysql        0 Aug 4 08:03 #sql_89b_0.MYD

 

-rw-rw---- 1 mysql  mysql     1024 Aug 4 08:03 #sql_89b_0.MYI

 

[root@zt_dbm1_13_11 ~]#

 

 

看到时间是8月4日早上8点3分产生的临时文件，现在已经下午4点了，还存在没有释放，奇怪了，难道是当时一个复杂的慢查询导致的吗？或者是其它客户端的诡异问题？

 

 

 

解决办法：

 

尝试下移走这2个临时文件，应该就可以了。

 

[root@zt_dbm1_13_11 ~]# mv/tmp/#sql_89b_0.* /home/mysql/

 

[root@zt_dbm1_13_11 ~]#

 

 

然后让同事再查询，就ok了，他能正常执行查询sql语句了。

 

猜测是这样的，在早晨8:03分的时候，有个sql发起查询，然后消耗资源比较多，但是客户端突然因为每种原因死掉了，导致mysql执行查询生成的这个临时文件卡住了无法返回，然后就一直存在着。等下次去执行相同的记录，那么就会告知临时文件已经存在了，无法执行了。

 

而且也解释通了啥别人的电脑的客户端连接数据库没有报错，就那个同事的客户端连接报错的原因，是因为他的客户端分配的临时空间被占据了，而我mv移掉他以前占据的空间的时候，他重新执行查询就能顺利执行成功了。