?1.? 現(xiàn)象
巡檢時發(fā)現(xiàn)服務(wù)器磁盤空間不足，通過查看大文件進(jìn)行篩選是發(fā)現(xiàn)有幾個#sql開頭的文件,且存在超過100G及10G以上的文件。
2. 原因
如果MySQL在一個 ALTER TABLE操作(ALGORITHM=INPLACE)的中間退出，那么可能會留下一個占用系統(tǒng)空間的臨時表。例如，在對一張表（大表）添加索引時中途中斷、磁盤不足導(dǎo)致異?；蛘谔砑铀饕龝r實例被kill等等情況所致。
注意：?此類表空間文件不能直接rm -f的方式物理刪除，因為該信息記錄在ibdata的共享表空間里，直接刪除后，后續(xù)實例重啟時會出現(xiàn)錯誤。
3. 處理方法
3.1?? 同時存在.frm 和.ibd名稱相同的文件
如果 #sql-*.ibd 和 #sql-*.frm兩個文件都存在數(shù)據(jù)目錄里的話，可以直接drop table。但注意刪除時候表名的變化。
由于臨時表的frm和idb文件名不同，需要重命名 .frm文件
mv \#sql-36ab_2.frm \#sql-ib87-856498050.frm
/* 直接刪除，表名前加#mysql50? */
oot@testdb01:42:57>DROP? TABLE? ?`#mysql50##sql-ib87-856498050`;
注： #mysql50#前綴是MySQL 5.1中引入的文件名安全編碼。另外，表名因不符合命名規(guī)范，想要執(zhí)行該腳本需要將表名用反引號括起來。
3.2? 創(chuàng)建新表方式刪除
因為本例中沒有存在.frm 和.ibd名稱相同的文件的情況，因此采用創(chuàng)建一張與ibd表空間對應(yīng)的結(jié)構(gòu)（字段名及索引）一致的表，然后將frm文件拷貝為和ibd一致的文件，再進(jìn)行刪除。
下面處理截圖中#sql-ib1516-2335726735.ibd文件，步驟如下：
a） 創(chuàng)建一張與#sql-ib1516-2335726735相同的表
root@testdb08:47:35>createtablecompany20191216like? company;
Query OK, 0rows affected (0.05 sec)
root@testdb08:48:59>exitBye
b） 拷貝為#sql-ib1516-2335726735.frm的定義文件
[root@db4 testdb]#cp-p? company20191216.frm? \#sql-ib1516-2335726735.frm
? c)? 刪除表
因為上一步拷貝時使用-p的方式，即權(quán)限和原文件權(quán)限一致，屬主及group均為mysql,因此可以直接在數(shù)據(jù)庫里讀取刪除，如果權(quán)限不對，必須先修改文件權(quán)限。
root@testdb08:49:54>droptable`#mysql50##sql-ib1516-2335726735`;
Query OK, 0rows affected (6.65sec)
此時，135G的文件就已經(jīng)刪掉了（其實另一個文件#sql-821_2.frm文件也一并刪了）
?注： 刪除這種100G的表不建議直接刪除，而是通過創(chuàng)建硬鏈接的方式處理。
3.3? 修改frm文件名與ibd文件名一致
上一步中刪除ibd文件時，其中一個frm也自動刪除了。為此，嘗試通過修改frm文件名和ibd文件名一致的方式處理。但要注意，由于不確定是否結(jié)構(gòu)一致，修改后可能異常，但如果沒有暴力處理，通常均可以成功。如下：
a)? 修改frm文件名與ibd文件名一致
[root@db4 testdb]#mv\#sql-a846_2.frm? \#sql-ib1570-121877015.frm
b） 刪除表
root@testdb01:41:06>DROPTABLE`#mysql50##sql-ib1570-121877015`;
Query OK, 0rows affected (1.70sec)
done!
其實還有其他的方式處理，大家可以自行測試。
