技術分享 | MySQL 碎片問題

原創做者： 宗楊

---

MySQL 的碎片是 MySQL 運維過程當中比較常見的問題，碎片的存在十分影響數據庫的性能，本文將對 MySQL 碎片進行一次講解。

 

判斷方法：

MySQL 的碎片是否產生，經過查看

show table status from table_name\G;

這個命令中 Data_free 字段，若是該字段不爲 0，則產生了數據碎片。

 

產生的緣由：

1. 常常進行 delete 操做

常常進行 delete 操做，產生空白空間，若是進行新的插入操做，MySQL將嘗試利用這些留空的區域，但仍然沒法將其完全佔用，長此以往就產生了碎片；

演示：

建立一張表，往裏面插入數據，進行一個帶有 where 條件或者 limit 的 delete 操做，刪除先後對比一下 Data_free 的變化。

刪除前：

刪除後：

Data_free 不爲 0，說明有碎片；

 

2. update 更新

update 更新可變長度的字段(例如 varchar 類型)，將長的字符串更新成短的。以前存儲的內容長，後來存儲是短的，即便後來插入新數據，那麼有一些空白區域仍是沒能有效利用的。

演示：

建立一張表，往裏面插入一條數據，進行一個 update 操做，先後對比一下 Data_free 的變化。

CREATE TABLE `t1` ( `k` varchar(3000) DEFAULT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8;

更新語句：update t1 set k='aaa';

更新前長度：223 Data_free：0

更新後長度：3 Data_free：204

Data_free 不爲 0，說明有碎片；

 

產生影響：

1. 因爲碎片空間是不連續的，致使這些空間不能充分被利用；

2. 因爲碎片的存在，致使數據庫的磁盤 I/O 操做變成離散隨機讀寫，加劇了磁盤 I/O 的負擔。

 

清理辦法：

• MyISAM：optimize table 表名；（OPTIMIZE 能夠整理數據文件,並重排索引）

• Innodb：

1. ALTER TABLE tablename ENGINE=InnoDB；(重建表存儲引擎，從新組織數據)

2. 進行一次數據的導入導出

碎片清理的性能對比：

引用我以前一個生產庫的數據，對比一下清理先後的差別。

空間對比：

庫名	清理前大小	清理後大小
facebook	2.2G	1.1G
instagram	40G	22G
linkedin	555M	208M
googleplus	19G	8.4G
twitter	107G	44G

SQL執行速度：

select count(*) from test.twitter_11;

修改前：1 row in set (7.37 sec)

修改後：1 row in set (1.28 sec)

 

結論：

經過對比，能夠看到碎片清理先後，節省了不少空間，SQL執行效率更快。因此，在平常運維工做中，應對碎片進行按期清理，保證數據庫有穩定的性能。