幾周之前搭建完anemometer之后并沒(méi)有對(duì)其進(jìn)行維護(hù)，最近查詢中間庫(kù)的空間時(shí)發(fā)現(xiàn)anemometer下面對(duì)應(yīng)的slow_query_log庫(kù)文件已經(jīng)達(dá)到了127G之多

測(cè)試庫(kù)上難得看到這么大的表，干脆用來(lái)實(shí)驗(yàn)一下在線刪除大表

在線直接干58G的大表

直接在線上drop 58G的那張表，通過(guò)iostat -dxm 5可以看到畫風(fēng)是下圖這樣的

與此同時(shí)這個(gè)操作讓中間庫(kù)幾乎是hang住了，連登陸都在等待

這個(gè)drop的操作持續(xù)了將近2分鐘

正確姿勢(shì)干70G大表

#進(jìn)入到表空間路徑下，制作硬連接

ln global_query_review_history.ibd global_query_review_history.ibd.h

ln global_query_review_history.frm global_query_review_history.frm.h

#登陸MySQL執(zhí)行drop table，這里的操作是秒刪

drop table?global_query_review_history;

操作之后就只剩下硬鏈接了

如果用rm去刪除的話，在高峰期還是會(huì)對(duì)I/O造成影響

采用truncate命令去刪除大表（也可以選一個(gè)業(yè)務(wù)低峰期去rm硬鏈接）

truncate -s 0 global_query_review_history.ibd.h

truncate -s 0 global_query_review_history.frm.h

PS：truncate這個(gè)語(yǔ)法也挺恐怖的，跟rm一樣危險(xiǎn)而且我們?nèi)粘Ｊ褂帽容^少，之前參照野雞文章的做法去執(zhí)行了一下操作，測(cè)試庫(kù)的所有文件都被削減了。

穩(wěn)妥起見(jiàn)，建議在前一步做ln的時(shí)候，把硬鏈接做到一個(gè)單獨(dú)的文件夾下，避免truncate的誤操作