mysql表太大删不掉_MySQL删除大表的经验教训和总结

今天一不小心删除了一张表大约2000--3000万的数据，以前在这方面有个教训的，一时疏忽，直接使用drop table sms_mapping命令删除，最后的结果:

1、整个数据库给HANG住了，keepalived的VIP跳到另外一台机器

2、导致业务服务器立马不能正常工作了，业务服务器产生大量的CLOSE_WAIT，不能连接进来

今天写出来，忘同行的注意，原因如下：

1、drop table的过程中所有的操作被HANG住了，这是因为innodb会维护一个全局独占锁(在table cache上面)，直到drop table完成后才会释放。

2、我们常用的EXT3，EXT4，NTFS等文件系统要删除一个大文件，是需要点时间的。造成大量的随机I / O。然而事实上,有时候它比你想象的更能影响MySQL的性能。

当您运行DROP TABLE时,会有好几件事情需要去做:对表进行write lock,这样它不会被其他线程使用;存储引擎删除数据文件;当然,最后MySQL会删除表定义文件(.frm文件)。这还不是所有的事，还有另外一件事需要去做：

代码:

VOID(pthread_mutex_lock(&LOCK_open));

error=

mysql_rm_table_part2(thd,

tables,

if_exists,

drop_temporary,

0,

0);

pthread_mutex_unlock(&LOCK_open);

这整段删除表操作的代码都被LOCK_open互斥信号量所包围。这个互斥信号量在MySQL中不少地方都用到过,但主要是表在开启或关闭的时候。这意味着，当LOCK_open锁定时，没有查询语句可以执行，因为他们阻止任何访问。

这就解释了在ext3文件系统上删除10GB的文件何时成为了痛苦的等待的开始。删除10GB的文件将持续一段时间，如果这是一个MySQL表,这段时间mutex里将会一直存在,而这个互斥会拖延所有查询。

利用os hard

link的原理实现大表的删除，当多个文件同时指向同一个inode时，这个inode的引用数N1，删除任意一个文件都很快。因为直接物理块没有删除，只是删除一个指针而已。当inode的引用数为1时，删除文件需要把整个物理数据块一并删除，因此比较耗时！

如下：

ln sms_mapping.ibd sms_mapping.hdlk

drop table sms_mapping;

在rm sms_mapping.ibd；

这样能大大的减少HANG 住的时间，虽然多操作几步，相信还是值得的。