mysql快速删除大表

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

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

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

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

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

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

OK，咱们用的就是上面的原理。
先给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工具集中，须要另外安装。

详情，你们能够去百度一下安装教程。另外，网上有流传一些文章，这些文章对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下建立硬连接，应该能完成相似功能。