同事连接数据库，查询数据报错了，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移掉他以前占据的空间的时候，他重新执行查询就能顺利执行成功了。