Oracle大表的删除： http://blog.itpub.net/26736162/viewspace-2141248/

在DROP TABLE 过程中，所有操作都会被HANG住。
这是因为INNODB会维护一个全局独占锁（在table cache上面），直到DROP TABLE完成才释放。
在我们常用的ext3,ext4，ntfs文件系统，要删除一个大文件（几十G，甚至几百G）还是需要点时间的。
下面我们介绍一个快速DROP table 的方法； 不管多大的表,INNODB 都可以很快返回，表删除完成；
实现：巧用LINK（硬链接）

实测：

root@127.0.0.1  : test 21:38:00> show table status like ‘tt’ \G
*************************** 1. row ***************************
Name: tt
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 151789128
Avg_row_length: 72
Data_length: 11011096576
Max_data_length: 0
Index_length: 5206179840
Data_free: 7340032
Auto_increment: NULL
Create_time: 2011-05-18 14:55:08
Update_time: NULL
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.22 sec)

root@127.0.0.1  : test 21:39:34> drop table tt ;
Query OK, 0 rows affected (25.01 sec)

删除一个11G的表用时25秒左右（硬件不同，时间不同）；

下面我们来对另一个更大的表进行删除；
但之前，我们需要对这个表的数据文件做一个硬连接：

root@ # ln stock.ibd stock.id.hdlk
root@ # ls stock.* -l
-rw-rw—- 1  MySQL  mysql        9196 Apr 14 23:03 stock.frm
-rw-r–r– 2 mysql mysql 19096666112 Apr 15 09:55 stock.ibd
-rw-r–r– 2 mysql mysql 19096666112 Apr 15 09:55 stock.id.hdlk

你会发现stock.ibd的INODES属性变成了2；

下面我们继续来删表。

root@127.0.0.1  : test 21:44:37> show table status like ‘stock’ \G
*************************** 1. row ***************************
Name: stock
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 49916863
Avg_row_length: 356
Data_length: 17799577600
Max_data_length: 0
Index_length: 1025507328
Data_free: 4194304
Auto_increment: NULL
Create_time: 2011-05-18 14:55:08
Update_time: NULL
Check_time: NULL
Collation: utf8_general_ci
Checksum: NULL
Create_options:
Comment:
1 row in set (0.23 sec)

root@127.0.0.1  : test 21:39:34> drop table stock ;
Query OK, 0 rows affected (0.99 sec)

1秒不到就删除完成； 也就是DROP TABLE不用再HANG这么久了。
但table是删除了，数据文件还在，所以你还需要最后数据文件给删除。

root # ll
total 19096666112
-rw-r–r– 2 mysql mysql 19096666112 Apr 15 09:55 stock.id.hdlk
root # rm stock.id.hdlk
虽然DROP TABLE 多绕了几步。(如果你有一个比较可靠的自运行程序（自动为大表建立硬链接，并会自动删除过期的硬链接文件），就会显得不那么繁琐。)
这样做能大大减少MYSQL HANG住的时间； 相信还是值得的。

至于原理: 就是利用OS HARD LINK的原理,
当多个文件名同时指向同一个INODE时,这个INODE的引用数N>1, 删除其中任何一个文件名都会很快.
因为其直接的物理文件块没有被删除.只是删除了一个指针而已;
当INODE的引用数N=1时, 删除文件需要去把这个文件相关的所有数据块清除,所以会比较耗时;

【问题隐患】

由于业务需求不断变化，可能在DB中存在超大表占用空间或影响性能；对这些表的处理操作，容易造成 MySQL 性能急剧下降，IO性能占用严重等。先前有在生产库drop table造成服务不可用；rm 大文件造成io跑满，引发应用容灾；对大表的操作越轻柔越好。

【解决办法】

1.通过硬链接减少mysql DDL时间，加快锁释放

2.通过truncate分段删除文件，避免IO hang

【生产案例】

某对mysql主备，主库写入较大时发现空间不足，需要紧急清理废弃大表，但不能影响应用访问响应：

$ll /u01/mysql/data/test/tmp_large.ibd

-rw-r-– 1 mysql dba 289591525376 Mar 30  2012 tmp_large.ibd

270GB的大表删除变更过程如下：

#（备库先做灰度）

ln tmp_large.ibd /u01/bak/tmp_tbl.ibd  #建立硬链接

-rw-r-– 2 mysql dba 289591525376 Mar 30  2012 tmp_large.ibd

set session sql_log_bin=0;

#不计入bin log节省性能，并且防止主备不一致

desc test.tmp_large;

drop table test.tmp_large;

Query OK, 0 rows affected （10.46 sec）

mysql -uroot -e “start slave;”

cd /u01/bak;

screen -S weixi_drop_table  for i in `seq 270 -1 1 ` ;

do sleep 2;

truncate -s ${i}G tmp_tbl.ibd;done

rm -rf tmp_tbl.ibd

【性能比较】

中间ctrl-C一次，可以看到truncate前后io的对比情况，基本上影响不大

文件大小也成功更新

【工具介绍】

truncate – shrink or extend the size of a file to the specified size

#来自coreutils工具集

wget  ftp.gnu.org/gnu/coreutils/coreutils-8.9.tar.gz

tar -zxvf coreutils-8.9.tar.gz

cd coreutils-8.9  ./configure

make

sudo cp src/truncate /usr/bin/

Innodb中mysql快速删除2T的大表方法示例

drop table erp

innodb_file_per_table = 1

mysql> show variables like '%per_table';
+-----------------------+-------+
| Variable_name  | Value |
+-----------------------+-------+
| innodb_file_per_table | OFF |
+-----------------------+-------+

mysql> system ls -l /data/mysql/mytest/

-rw-r----- 1 mysql mysql  9023 8 18 05:21 erp.frm
-rw-r----- 1 mysql mysql 2356792000512 8 18 05:21 erp.ibd

system ln /data/mysql/mytest/erp.ibd /data/mysql/mytest/erp.ibd.hdlk

mysql> drop table erp;
Query OK, 0 rows affected (0.99 sec)

TRUNCATE=/usr/local/bin/truncate
for i in `seq 2194 -10 10 `;
do sleep 2$TRUNCATE -s ${i}G /data/mysql/mytest/erp.ibd.hdlk
done
rm -rf /data/mysql/mytest/erp.ibd.hdlk ;

About Me

............................................................................................................................................. ● 本文整理自网络 ● 本文在itpub（ http://blog.itpub.net/26736162/abstract/1/ ）、博客园（ http://www.cnblogs.com/lhrbest ）和个人微信公众号（ xiaomaimiaolhr ）上有同步更新 ● 本文itpub地址： http://blog.itpub.net/26736162/abstract/1/ ● 本文博客园地址： http://www.cnblogs.com/lhrbest ● 本文pdf版、个人简介及小麦苗云盘地址： http://blog.itpub.net/26736162/viewspace-1624453/ ● 数据库笔试面试题库及解答： http://blog.itpub.net/26736162/viewspace-2134706/ ● DBA宝典今日头条号地址： http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826 ............................................................................................................................................. ● QQ群号： 230161599 （满） 、618766405 ● 微信群：可加我微 信，我拉大家进群，非诚勿扰 ● 联系我请加QQ好友 （ 646634621 ） ，注明添加缘由 ● 于 2017-08-01 09:00 ~ 2017-08-31 22:00 在魔都完成 ● 文章内容来源于小麦苗的学习笔记，部分整理自网络，若有侵权或不当之处还请谅解 ● 版权所有，欢迎分享本文，转载请保留出处 ............................................................................................................................................. ● 小麦苗的微店 ： https://weidian.com/s/793741433?wfr=c&ifr=shopdetail ● 小麦苗出版的数据库类丛书 ： http://blog.itpub.net/26736162/viewspace-2142121/ ............................................................................................................................................. 使用 微信客户端 扫描下面的二维码来关注小麦苗的微信公众号（ xiaomaimiaolhr ）及QQ群（DBA宝典）， 学习最实用的数据库技术。 小麦苗的微信公众号      小麦苗的DBA宝典QQ群1     小麦苗的 DBA宝典 QQ群2         小麦苗的微店 .............................................................................................................................................

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26736162/viewspace-2143135/，如需转载，请注明出处，否则将追究法律责任。