在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，研發童鞋啥都得幹。但願你們有所收穫吧。