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