在MySQL中如何有效的删除一个大表？

在MySQL中如何有效的删除一个大表？      

  在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的大表方法示例

这篇文章主要给你们介绍了关于Innodb中mysql快速删除2T的大表的相关资料，文中经过示例代码介绍的很是详细，对你们的学习或者工做具备必定的参考学习价值，须要的朋友们下面随着小编来一

前言

本文主要给你们介绍了关于Innodb中mysql快速删除2T的大表的相关内容，分享出来供你们参考学习，下面话很少说了，来一块儿看看详细的介绍吧

来，先来看小漫画陶冶一下情操

OK，这里就说了。假设，你有一个表erp,若是你直接进行下面的命令

drop table erp

 

这个时候全部的mysql的相关进程都会中止，直到drop结束，mysql才会恢复执行。出现这个状况的缘由就是由于，在drop table的时候，innodb维护了一个全局锁，drop完毕锁就释放了。

这意味着，若是在白天，访问量很是大的时候，若是你在不作任何处理措施的状况下，执行了删大表的命令，整个mysql就挂在那了，在删表期间，QPS会严重下滑，而后产品经理就来找你喝茶了。因此才有了漫画中的一幕，你能够在晚上十二点，夜深人静的时候再删。

固然，有的人不服，可能会说："你能够写一个删除表的存储过程，在晚上没啥访问量的时候运行一次就行。"
我心里一惊，细想一下，只能说："你们仍是别抬杠了，仍是听我说一下业内通用作法。"

一个假设

先说明一下，在这里有一个前提，mysql开启了独立表空间，MySQL5.6.7以后默认开启。

也就是在my.cnf中，有这么一条配置(这些是属于mysql优化的知识，后期给你们介绍)

innodb_file_per_table = 1

 

查看表空间状态，用下面的命令

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

 

若是innodb_file_per_table的value值为OFF，表明采用的是共享表空间。

若是innodb_file_per_table的value值为ON ，表明采用的是独立表空间。

因而，你们要问我，独立表空间和共享表空间的区别？

共享表空间：某一个数据库的全部的表数据，索引文件所有放在一个文件中，默认这个共享表空间的文件路径在data目录下。 默认的文件名为:ibdata1(此文件，能够扩展成多个)。注意，在这种方式下，运维超级不方便。你看，全部数据都在一个文件里，要对单表维护，十分不方便。另外，你在作delete操做的时候，文件内会留下不少间隙，ibdata1文件不会自动收缩。换句话说，使用共享表空间来存储数据，会遭遇drop table以后，空间没法释放的问题。

独立表空间:每个表都以独立方式来部署，每一个表都有一个.frm表描述文件，还有一个.ibd文件。

.frm文件：保存了每一个表的元数据，包括表结构的定义等，该文件与数据库引擎无关。

.ibd文件：保存了每一个表的数据和索引的文件。

注意，在这种方式下，每一个表都有自已独立的表空间，这样运维起来方便，能够实现单表在不一样数据库之间的移动。另外，在执行drop table操做的时候，是能够自动回收表空间。在执行delete操做后，能够经过alter table TableName engine=innodb能够整理碎片，回收部分表空间。

ps：  my.cnf中的datadir就是用来设置数据存储目录

好了，上面巴拉巴拉了一大堆，我只想说一个事情:

在绝大部分状况下，运维必定会为mysql选择独立表空间的存储方式，由于采用独立表空间的方式，从性能优化和运维难易角度来讲，实在强太多。

因此，我在一开始所提到的前提，mysql须要开启独立表空间。这个假设，百分九十的状况下是成立的。若是真的遇到了，大家公司的mysql采用的是共享表空间的状况，请你和大家家的运维谈谈心，问问为啥用共享表空间。

正确姿式

假设，咱们有datadir = /data/mysql/,另外，咱们有有一个database,名为mytest。在数据库mytest中，有一个表，名为erp，执行下列命令

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

 

frm和ibd的做用，上面介绍过了。如今就是erp.ibd文件太大，因此删除卡住了。

如何解决这个问题呢？

这里须要利用了linux中硬连接的知识，来进行快速删除。下面容我上《鸟哥的私房菜》中的一些内容，

软连接其实你们能够类比理解为windows中的快捷方式，就很少介绍了，主要介绍一下硬连接。

至于这个硬连接，我简单说一下，不想贴一大堆话过来，看起来太累。

就是对于真正存储的文件来讲，有一个

而后呢有一个文件名指向上面的node Index

那么，所谓的硬连接，就是不止一个文件名指向node Index，有好几个文件名指向node Index。

假设，这会又有一个文件名指向上面的node Index，即

这个时候，你作了删除文件名(1)的操做，linux系统检测到，还有一个文件名(2)指向node Index，所以并不会真正的把文件删了，而是把步骤(2)的引用给删了，这步操做很是快，毕竟只是删除引用。因而图就变成了这样

接下来，你再作删除文件名(2)的操做，linux系统检测到，没有其余文件名指向该node Index，就会删除真正的存储文件，这步操做，是删真正的文件，因此比较慢。

OK，咱们用的就是上面的原理。

先给erp.ibd创建一个硬连接，利用ln命令

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

 

此时，文件目录以下所示

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

你会发现，多了一个erp.ibd.hdlk文件，且erp.ibd和erp.ibd.hdlk的inode均为2。

此时，你执行drop table操做

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

 

你会发现，不到1秒就删除了。由于，此时有两个文件名称(erp.ibd和erp.ibd.hdlk),同时指向一个inode.这个时候，执行删除操做，只是把引用给删了，因此很是快。

那么，这时的删除，已经把table从mysql中删除。可是磁盘空间，还没释放，由于还剩一个文件erp.ibd.hdlk。

如何正确的删除erp.ibd.hdlk呢？

若是你没啥经验，必定会回答我，用rm命令来删。这里须要说明的是，在生产环境，直接用rm命令来删大文件，会形成磁盘IO开销飙升,CPU负载太高，是会影响其余程序运行的。

那么，这种时候，就是应该用truncate命令来删，truncate命令在coreutils工具集中。

详情，你们能够去百度一下，有人对rm和truncate命令，专程测试过，truncate命令对磁盘IO，CPU负载几乎无影响。

删除脚本以下

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 ;

 

从2194G开始，每次缩减10G，停2秒，继续，直到文件只剩10G，最后使用rm命令删除剩余的部分。

其余状况

这里指的是，若是数据库是部署在windows上怎么办。这个问题，我来回答，其实不够专业。由于我出道以来，还没碰到过，生产环境上，mysql是部在windows上的。假设真的碰到了，windows下有一个工具叫mklink，是在windows下建立硬连接锁用，应该能完成相似功能

总结

本文所讲的内容，中小型公司的研发比较容易遇到。由于中小型公司没有专业的DBA，研发童鞋啥都得干。但愿你们有所收获吧。