清理服務器空間遇到的mysql問題

背景：公司生產環境服務器空間報警，超過80%，緊急檢查發現是mysql備份服務器，有一個記錄明細的大表，佔用空間150G左右。找到了問題，就要解決他。計劃將此表移走，重新建一個空新表，繼續記錄。在操作過程中因爲失誤，導致多饒了好多流程，現在記錄下來。
原計劃：
1、備份這個表，使用xtrabackup
2、對錶空間進行硬鏈接（ln命令），目的是不刪除文件本身，而只刪除其指針，從而達到快速刪除，不影響使用，不佔用資源的目的。（依賴原理：OS HARD LINK 當多個文件名同時指向同一個INODE時,這個INODE的引用數N>1, 刪除其中任何一個文件名只是刪除了一個指針而已，不會刪除數據文件。當INODE的引用數N=1時, 刪除文件需要去把這個文件相關的所有數據塊清除,所以會比較耗時）。
3、使用drop刪除表，最後刪除表文件。
問題：然而理想很豐滿現實很骨幹，打我登陸服務器之後，發現服務器剩餘的空間不足以讓我進行硬鏈接。這就尷尬了，沒辦法，只能另找其他方法。
實際操作：
1、備份完數據
2、思索怎麼把大表刪除或者移走。最後決定將表空間重命名（mv），然後再操作，但是在mv重命名過程中，因爲失誤將ibd文件覆蓋了，導致的問題是此大文件瞬間消失了，但是查看服務器空間發現其所佔空間大小依然存在。按照道理來說，如果mv導致文件覆蓋，文件相當於是被刪除了，空間也應該釋放了，然而沒有。考慮到文件爲mysql表空間文件，可能存在鏈接問題，重啓mysql後，發現硬盤空間釋放。
3、解決了硬盤空間問題，迎來了新的問題。在原數據庫中建立同名表的時候，數據庫一直提示表已存在，這就是直接刪除表空間遺留下的問題。因爲要新建一個空表，繼續使用，所以也要解決這個問題。當然如果條件允許的話，可以另見一個結構一樣表名稱不一樣的新表使用。我認爲既然遇到了，就解決這個問題。
4、登陸數據庫進行drop表測試，發現提示找不到這張表t1。考慮到表空間不存在，手動建一個空的表空間。首先是建了一張結構一樣但是表名稱不一樣的表t2，複製t2的表空間並重命名爲t1的表空間。重啓數據庫，然後再進入數據庫，先分離表空間，再drop表，發現可以成功。然後新建t1表，也可以成功。最後將t2表刪除。
5、此操作雖然沒有問題，但是t1表中原始數據會丟失，所以在操作數據庫之前一定要備份數據。
總結：雖然這是一個不大不小的問題，特別記錄下來，有需要的朋友可以看一下。當然也有一個意外收穫，那就是這樣刪除比drop速度要快得多，而且還不佔用資源。