1. 為啥磁盤還是滿的 ?
應該是 MySQL 并沒有真正清理掉這部分數(shù)據(jù)，而是假刪除。這種假刪除的行為在 Linux 中并不稀罕，屬于常規(guī)操作，算是一種策思想，所以斷定 MySQL 也這么干了。
查看碎片信息命令：
SELECT * from
(
SELECT CONCAT(table_schema,'.',table_name) AS 'table_name',
table_rows AS 'Number of Rows',
CONCAT(ROUND(data_length/(1024*1024),6),' M') AS 'data_size',
CONCAT(ROUND(index_length/(1024*1024),6),' M') AS 'index_size' ,
CONCAT(ROUND(data_free/(1024*1024),6),' M') AS'data_free',
ENGINE as 'engine'
FROM information_schema.TABLES
WHERE table_schema = #{庫名}
) t ORDER BY data_free DESC;
- data_size ：數(shù)據(jù)的大小
- index_size ：索引的大小
- data_free ：數(shù)據(jù)在使用中的留存空間
- engine ：表引擎名稱
其中 data_free 代表磁盤碎片的大小， 也就是需要消滅清理的地方。
2. 磁盤清理神器
不同的 MySQL 存儲引擎清理方式有所不同。
SHOW ENGINES; // 查看引擎命令
MySQL 中有多種存儲引擎，常用的有 MyISAM 和 InnoDB，先看看這兩個有什么特點：
3.1 MyISAM 引擎
MyISAM 基于 ISAM 存儲引擎，并對其進行擴展。
- 支持 B-tree/FullText/R-tree 索引類型；
- 鎖級別為表鎖，表鎖優(yōu)點是開銷小，加鎖快；缺點是鎖粒度大，發(fā)生鎖沖動概率較高，容納并發(fā)能力低，這個引擎適合查詢?yōu)橹鞯臉I(yè)務；
- 此引擎不支持事務，也不支持外鍵；
- BLOB 和 TEXT 列可以被索引；
- 強調(diào)了 快速讀取操作，比如他存儲表的行數(shù)，只需要直接讀取已經(jīng)保存好的值而不需要進行全表掃描。
3.2 InnoDB 引擎
- 支持事務，支持回滾，支持外鍵；
- 支持 Hash/B-tree 索引類型；
- 鎖級別為行鎖，行鎖優(yōu)點是適用于高并發(fā)的頻繁修改，高并發(fā)是性能優(yōu)于 MyISAM；
- 系統(tǒng)小號較大，不僅緩存自身，也緩存數(shù)據(jù)，相比于 MyISAM 需要更大的內(nèi)存。
3.3 操作命令
InnoDB 可以選擇的操作命令包括：
OPTIMIZE TABLE tablename
ALTER TABLE tablename ENGINE = InnoDB
實際上運行上述清理命令時，MySQL 會鎖定表，清理的數(shù)據(jù)越大，消耗的時間越久，因此這個操作一定要在夜深人靜的時候操作。
命令好像是一句廢話，它實際執(zhí)行的是一個空的 ALTER 命令會重建整個表，刪除未使用的空白空間。
4. MySQL 為什么會有碎片
以 InnoDB 存儲引擎為例，來看看為什么會出現(xiàn)碎片。
- 當執(zhí)行刪除一些行，這些行只是標記為“已刪除”，而不是真的從索引中物理刪除了，因而空間并沒有真正的被釋放回收。
- 大量隨機刪除操作，會造成不連續(xù)的空白空間，當插入數(shù)據(jù)時，這些空白空間會被優(yōu)先利用起來，但是肯定不會被全部利用起來，也就會存在數(shù)據(jù)碎片。
- 大量 UPDATE 操作，InnoDB 的最小物理存儲分配單位是頁，在更新變長時 UPDATE 也可能導致頁分裂，頻繁的也分裂，頁會變得稀疏，并且被不規(guī)則的填充，最終會有碎片，比如原來 256 字節(jié)修改后是 128 字節(jié)，那么可能出現(xiàn) 128 字節(jié)左右的空洞無法被利用。
