几周之前搭建完anemometer之后并没有对其进行维护，最近查询中间库的空间时发现anemometer下面对应的slow_query_log库文件已经达到了127G之多

测试库上难得看到这么大的表，干脆用来实验一下在线删除大表

---

在线直接干58G的大表

直接在线上drop 58G的那张表，通过iostat -dxm 5可以看到画风是下图这样的

与此同时这个操作让中间库几乎是hang住了，连登陆都在等待

这个drop的操作持续了将近2分钟

---

正确姿势干70G大表

#进入到表空间路径下，制作硬连接

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执行drop table，这里的操作是秒删

drop table global_query_review_history;

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

如果用rm去删除的话，在高峰期还是会对I/O造成影响

采用truncate命令去删除大表（也可以选一个业务低峰期去rm硬链接）

truncate -s 0 global_query_review_history.ibd.h

truncate -s 0 global_query_review_history.frm.h

---

PS：truncate这个语法也挺恐怖的，跟rm一样危险而且我们日常使用比较少，之前参照野鸡文章的做法去执行了一下操作，测试库的所有文件都被削减了。

稳妥起见，建议在前一步做ln的时候，把硬链接做到一个单独的文件夹下，避免truncate的误操作