轉載自：https://blog.csdn.net/mchdba/article/details/52122724

同事連線資料庫，查詢資料報錯了，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也沒有看到死鎖或者其他異常資訊；

那麼問題在哪裡呢？去看下報錯的原始檔案吧

[[email protected]_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

[[email protected]_dbm1_13_11 ~]#

看到時間是8月4日早上8點3分產生的臨時檔案，現在已經下午4點了，還存在沒有釋放，奇怪了，難道是當時一個複雜的慢查詢導致的嗎？或者是其它客戶端的詭異問題？

解決辦法：

嘗試下移走這2個臨時檔案，應該就可以了。

[[email protected]_dbm1_13_11 ~]# mv/tmp/#sql_89b_0.* /home/mysql/

[[email protected]_dbm1_13_11 ~]#

然後讓同事再查詢，就ok了，他能正常執行查詢sql語句了。

猜測是這樣的，在早晨8:03分的時候，有個sql發起查詢，然後消耗資源比較多，但是客戶端突然因為每種原因死掉了，導致mysql執行查詢生成的這個臨時檔案卡住了無法返回，然後就一直存在著。等下次去執行相同的記錄，那麼就會告知臨時檔案已經存在了，無法執行了。

而且也解釋通了啥別人的電腦的客戶端連線資料庫沒有報錯，就那個同事的客戶端連線報錯的原因，是因為他的客戶端分配的臨時空間被佔據了，而我mv移掉他以前佔據的空間的時候，他重新執行查詢就能順利執行成功了。