转载-Innodb中MySQL如何快速删除2T的大表

转载一个写得非常好的帖子，原文地址：https://mp.weixin.qq.com/s/AWA0_fx0CQqN5MucfUm_KQ

 

 

小漫画

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

 

 

 

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

drop table erp

这个时候所有的mysql的相关进程都会停止，直到drop结束，mysql才会恢复执行。出现这个情况的原因就是因为，在drop table的时候，innodb维护了一个全局锁，drop完毕锁就释放了。
这意味着，如果在白天，访问量非常大的时候，如果你在不做任何处理措施的情况下，执行了删大表的命令，整个mysql就挂在那了，在删表期间，QPS会严重下滑，然后产品经理就来找你喝茶了。

所以才有了漫画中的一幕，你可以在晚上十二点，夜深人静的时候再删。
当然，有的人不服，可能会说："你可以写一个删除表的存储过程，在晚上没啥访问量的时候运行一次就行。"
我内心一惊，细想一下，只能说："大家还是别抬杠了，还是听我说一下业内通用做法。"

drop table 多说点，

mysql会将表定义和表数据全都删除，包括磁盘上的物理文件，也包括buffer pool中的内存数据。

这就分两步，第一步从buffer pool中删除，这会涉及到table_cache的lock，如果持有table_cache的lock，

这将导致其他查询都无法执行。这种情况在没有innodb_per_table之前尤为严重。

另外，mysql5.5.23之后添加lazy drop table功能，这个功能用来解决mutex on the LRU list。

其中心思想就是加锁，找到需要被删除的page，删除1024个page之后释放锁让其他thread工作，之后loop。

而percona的lazy drop处理起来更优雅一些，其会先加锁，然后找到需要被删除的page，标记，释放锁，后台慢慢删除。

 

 

之后就是第二步，这步在大容量表的时候更为消耗时间，那就是在os上删除物理文件。大家都知道在ext3上rm一个200G的文件会非常耗时，这是由于ext3存储数据的结构导致，如果一个很大的文件，

ext3的i_block无法直接存放，需要多层嵌套才能完全存储下，在这种情况下由于映射的层次多，并且由于多层映射也不会是顺序存储的，就导致了很大的随机IO，这就导致了删除物理文件非常慢的现象

在这种情况下，建议升级到ext4，这是由于ext4比ext3使用extent分配存储空间，其最大的优势就是顺序存储。

 

ext3文件系统

 

 

 

 ext4文件系统：

 

 

一个假设

先说明一下，在这里有一个前提，mysql开启了独立表空间，MySQL5.6.7之后默认开启。
也就是在my.cnf中，有这么一条配置(这些是属于mysql优化的知识，后期给大家介绍)

innodb_file_per_table = 1

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

 

如果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中的快捷方式，就不多介绍了，主要介绍一下硬链接。
至于这个硬链接，我简单说一下，不想贴一大堆话过来，看起来太累。
就是对于真正存储的文件来说，有一个Inode Index指向存储文件

 

然后呢有一个文件名指向的Inode Index

 

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

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

 

这个时候，你做了删除文件名(1)的操作，linux系统检测到，还有一个文件名(2)指向Inode Index，因此并不会真正的把文件删了，

而是把文件名(1)的引用给删了，这步操作非常快，毕竟只是删除引用。于是图就变成了这样

 

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

OK，我们用的就是上面的原理。总结如下：

当多个文件共同指向同一inode，inode链接数N>1，删除任何一个文件都是巨快因为，此时删除的仅仅是指向inode的指针而当N=1时，则不一样了，此时删除的文件相关的所有数据块，

所以慢在建立硬链接之后，mysql会认为rm了硬链接文件之后就算操作完毕，不会真正去删除物理文件从而提高了速度。但是对于服务器来说，实际的物理文件还在，如果手动rm，

还是会产生很多的io影响，这时候就用到了truncate这个工具。这个工具会根据指定的size大小进行逐步删除，会将对IO造成的影响降到最低。

硬链接与软链接的联系与区别

我们知道文件都有文件名与数据，这在 Linux 上被分成两个部分：用户数据 (user data) 与元数据 (metadata)。用户数据，即文件数据块 (data block)，数据块是记录文件真实内容的地方；而元数据则是文件的附加属性，

如文件大小、创建时间、所有者等信息。在 Linux 中，元数据中的 inode 号（inode 是文件元数据的一部分但其并不包含文件名，inode 号即索引节点号）才是文件的唯一标识而非文件名。文件名仅是为了方便人们的记忆和使用，

系统或程序通过 inode 号寻找正确的文件数据块。下图展示了程序通过文件名获取文件内容的过程。

 

 

 为解决文件的共享使用，Linux 系统引入了两种链接：硬链接 (hard link) 与软链接（又称符号链接，即 soft link 或 symbolic link）。链接为 Linux 系统解决了文件的共享使用，还带来了隐藏文件路径、

增加权限安全及节省存储等好处。若一个 inode 号对应多个文件名，则称这些文件为硬链接。换言之，硬链接就是同一个文件使用了多个别名（见 图 2.hard link 就是 file 的一个别名，他们有共同的 inode）。

硬链接可由命令 link 或 ln 创建。如下是对文件 oldfile 创建硬链接。

 

由于硬链接是有着相同 inode 号仅文件名不同的文件，因此硬链接存在以下几点特性： 文件有相同的 inode 及 data block； 只能对已存在的文件进行创建； 不能交叉文件系统进行硬链接的创建；

不能对目录进行创建，只可对文件创建； 删除一个硬链接文件并不影响其他有相同 inode 号的文件。

软链接与硬链接不同，若文件用户数据块中存放的内容是另一文件的路径名的指向，则该文件就是软连接。软链接就是一个普通文件，只是数据块内容有点特殊。软链接有着自己的 inode 号以及用户数据块（

因此软链接的创建与使用没有类似硬链接的诸多限制： 软链接有自己的文件属性及权限等； 可对不存在的文件或目录创建软链接； 软链接可交叉文件系统； 软链接可对文件或目录创建； 创建软链接时，链接计数 i_nlink 不会增加；

删除软链接并不影响被指向的文件，但若被指向的原文件被删除，则相关软连接被称为死链接（即 dangling link，若被指向路径文件被重新创建，死链接可恢复为正常的软链接）。

 软链接图示：

 

 

下面就是正确的删除过程：

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

mysql> 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的innode均为2。
此时，你执行drop table操作

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

你会发现，不到1秒就删除了。因为，此时有两个文件名称(erp.ibd和erp.ibd.hdlk),同时指向一个innode.这个时候，执行删除操作，只是把引用给删了，所以非常快。
那么，这时的删除，已经把table从mysql中删除。但是磁盘空间，还没释放，因为还剩一个文件erp.ibd.hdlk。
如何正确的删除erp.ibd.hdlk呢？
如果你没啥经验，一定会回答我，用rm命令来删。这里需要说明的是，在生产环境，直接用rm命令来删大文件，会造成磁盘IO开销飙升,CPU负载过高，是会影响其他程序运行的。
那么，这种时候，就是应该用truncate命令来进行删除。需要说明的是，truncate命令在coreutils工具集中，需要另外安装。

了解下truncate

此命令不仅能把文件的数据删成0字节，还可以缩减（甚至扩大）文件至指定的大小（通过 -s 选项指定文件大小值）

 

这里还可以看到一个“奇怪”的现象，本来已经缩至4字节的文件，把它扩展成1M以后，ls 和 wc 的结果显示大小确实是1M，但是 du 的结果却发现大小还是4字节。这也是要注意的地方之一，这种文件称为“空洞文件”，也就是说，文件的部分内容并没有实际存在于硬盘上（即没有分配对应的inode），只是“声称”有1M的大小而已。对于不存在于硬盘上的那部分字节，如果去读的话，也是不会报错的，会读到全0的数据。

详情，大家可以去百度一下安装教程。另外，网上有流传一些文章，这些文章对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下创建硬链接，应该能完成类似功能。