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>exitBye

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!

其實還有其他的方式處理，大家可以自行測試。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的c 没有mysql名称空间_MySQL如何删除#sql开头的临时表的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。