MySQL表碎片化（Table Fragmentation）的原因
關於MySQL中表碎片化（Table Fragmentation）產生的原因，簡單總結一下，MySQL Engine不同，碎片化的原因可能也有所差別。這裏沒有深入理解、分析這些差別。此文僅以InnoDB引擎爲主。總結如有不足或錯誤的地方，敬請指出。
InnoDB表的數據存儲在頁（page）中，每個頁可以存放多條記錄。這些記錄以樹形結構組織，這顆樹稱爲B+樹索引。表中數據和輔助索引都是使用B+樹結構。維護表中所有數據的這顆B+樹索引稱爲聚簇索引，通過主鍵來組織的。聚簇索引的葉子節點包含行中所有字段的值，輔助索引的葉子節點包含索引列和主鍵列。
在InnoDB中，刪除一些行，這些行只是被標記爲“已刪除”，而不是真的從索引中物理刪除了，因而空間也沒有真的被釋放回收。InnoDB的Purge線程會異步的來清理這些沒用的索引鍵和行。但是依然沒有把這些釋放出來的空間還給操作系統重新使用，因而會導致頁面中存在很多空洞。如果表結構中包含動態長度字段，那麼這些空洞甚至可能不能被InnoDB重新用來存新的行，因爲空間空間長度不足。關於這個你可以參考博客Overview of fragmented MySQL InnoDB tables。
另外，刪除數據就會導致頁（page）中出現空白空間，大量隨機的DELETE操作，必然會在數據文件中造成不連續的空白空間。而當插入數據時,這些空白空間則會被利用起來.於是造成了數據的存儲位置不連續。物理存儲順序與邏輯上的排序順序不同,這種就是數據碎片。
對於大量的UPDATE，也會產生文件碎片化 ， Innodb的最小物理存儲分配單位是頁(page)，而UPDATE也可能導致頁分裂（page split），頻繁的頁分裂，頁會變得稀疏，並且被不規則的填充，所以最終數據會有碎片。
表的數據存儲也可能碎片化。然而數據存儲的碎片化比索引更加複雜。有三種類型的數據碎片化。
##下面部分內容摘自【高性能MySQL】##
行碎片（Row fragmentation）
這種碎片指的是數據行被存儲爲多個地方的多個片段。即使查詢只從索引中訪問一行記錄。行碎片也會導致性能下降。
行間碎片（Intra-row fragmentaion）
行間碎片是指邏輯上順序的頁，或者行在磁盤上不是順序存儲的。行間碎片對諸如全表掃描和聚簇索引掃描之類的操作有很大的影響，因爲這些操作原本能夠從磁盤上順序存儲的數據中獲益。
剩餘空間碎片（Free space fragmentation）
剩餘空間碎片是指數據頁中有大量的空餘空間。這會導致服務器讀取大量不需要的數據。從而造成浪費。
對於MyISAM表，這三類碎片化都有可能發生。但InnoDB不會出現短小的行碎片；InnoDB會移動短小的行並寫到一個片段中。InnoDb會移動短小的行並重寫到一個片段中。
從二級索引中隨機插入或刪除可能會導致索引碎片化。碎片意味着磁盤上索引頁的物理排序不接近頁面上記錄的索引排序，或者64頁塊中有許多未使用的頁面被分配給索引。
碎片化的一個症狀是表格佔用的空間比“應該”佔用的空間多。多少確切地說，很難確定。所有 InnoDB 數據和索引都存儲在 B-trees 中，它們的 fill factor 可能在50％到100％之間變化。碎片的另一個症狀是像這樣的表掃描需要比“應該”花費更多的時間
MySQL中如何找出碎片化嚴重的表
關於MySQL中表碎片化，那麼如何找出MySQL中的碎片，一般有兩種方法。
方法1：使用show table status from xxxx like 'xxxx' \G;
第一個xxx:表所在的數據庫名稱，第二個xxx:要查詢的表名。這個方法其實不太實用。例如，只能單個表的查詢碎片化情況（難道一個數據庫要一個個表去試？），不能查詢某個數據庫或整個實例下所有表的碎片化等等。這裏僅僅作爲一個參考方法而已。
mysql> create table frag_tab_myisam
-> (
-> id int,
-> name varchar(63)
-> ) engine=MyISAM;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into frag_tab_myisam
-> values(1, 'it is only test row 1');
Query OK, 1 row affected (0.00 sec)
mysql>
mysql> insert into frag_tab_myisam
-> values(2, 'it is only test row 2');
Query OK, 1 row affected (0.00 sec)
mysql>
mysql>
mysql> insert into frag_tab_myisam
-> values(3, 'it is only test row 3');
Query OK, 1 row affected (0.00 sec)
mysql>
mysql> insert into frag_tab_myisam
-> values(4, 'it is only test row 4');
Query OK, 1 row affected (0.00 sec)
mysql>
mysql> show table status from kkk like 'frag_tab_myisam' \G;
如下截圖所示，如果沒有DML操作，Data_free的大小是0
然後我們在數據庫上刪除掉2條記錄，如下所示,Data_free的大小爲64KB大小了。
mysql> delete from frag_tab_myisam where id =1;
Query OK, 1 row affected (0.00 sec)
mysql> delete from frag_tab_myisam where id =3;
Query OK, 1 row affected (0.00 sec)
方法2：查詢information_schema.TABLES獲取表的碎片化信息。
如下所示，這個是我整理的一個查詢表碎片化的經典腳本。你可以在上面做很多衍生：例如，查詢某個數據庫的表碎片化情況。或者空閒空間超過50M大小的表。這個可以根據自己的需求設定查詢條件。在此略過。
SELECT CONCAT(table_schema, '.', table_name) AS TABLE_NAME
,engine AS TABLE_ENGINE
,table_type AS TABLE_TYPE
,table_rows AS TABLE_ROWS
,CONCAT(ROUND(data_length / ( 1024 * 1024), 2), 'M') AS TB_DATA_SIZE
,CONCAT(ROUND(index_length / ( 1024 * 1024), 2), 'M') AS TB_IDX_SIZE
,CONCAT(ROUND((data_length + index_length )
/ ( 1024 * 1024 ), 2), 'M') AS TOTAL_SIZE
,CASE WHEN data_length =0 THEN 0
ELSE ROUND(index_length / data_length, 2) END AS TB_INDX_RATE
,CONCAT(ROUND( data_free / 1024 / 1024,2), 'MB') AS TB_DATA_FREE
,CASE WHEN (data_length + index_length) = 0 THEN 0
ELSE ROUND(data_free/(data_length + index_length),2)
END AS TB_FRAG_RATE
FROM information_schema.TABLES
ORDER BY data_free DESC;
SELECT CONCAT(table_schema, '.', table_name) AS TABLE_NAME
,engine AS TABLE_ENGINE
,table_type AS TABLE_TYPE
,table_rows AS TABLE_ROWS
,CONCAT(ROUND(data_length / ( 1024 * 1024), 2), 'M') AS TB_DATA_SIZE
,CONCAT(ROUND(index_length / ( 1024 * 1024), 2), 'M') AS TB_IDX_SIZE
,CONCAT(ROUND((data_length + index_length )
/ ( 1024 * 1024 ), 2), 'M') AS TOTAL_SIZE
,CASE WHEN data_length =0 THEN 0
ELSE ROUND(index_length / data_length, 2) END AS TB_INDX_RATE
,CONCAT(ROUND( data_free / 1024 / 1024,2), 'MB') AS TB_DATA_FREE
,CASE WHEN (data_length + index_length) = 0 THEN 0
ELSE ROUND(data_free/(data_length + index_length),2)
END AS TB_FRAG_RATE
FROM information_schema.TABLES
WHERE ROUND(DATA_FREE/1024/1024,2) >=50
ORDER BY data_free DESC;
SELECT TABLE_SCHEMA
,TABLE_NAME
,ENGINE
,ROUND(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) AS SIZE_MB
,ROUND(DATA_FREE/1024/1024,2) AS FREE_SIZ_MB
FROM information_schema.TABLES
WHERE DATA_FREE >=10*1024*1024
ORDER BY FREE_SIZ_MB DESC;
MySQL中如何減低表的碎片
在MySQL中，可以使用OPTIMIZE TABLE、ALTER TABLE XXXX ENGINE = INNODB這兩種方法降低碎片，關於這兩者的簡單介紹如下：
OPTIMIZE TABLE table_name
OPTIMIZE TABLE 會重組表和索引的物理存儲，減少對存儲空間使用和提升訪問表時的IO效率。對每個表所做的確切更改取決於該表使用的存儲引擎
OPTIMIZE TABLE的支持表類型：INNODB,MYISAM, ARCHIVE，NDB；它會重組表數據和索引的物理頁，對於減少所佔空間和在訪問表時優化IO有效果。OPTIMIZE 操作會暫時鎖住表,而且數據量越大,耗費的時間也越長。
OPTIMIZE TABLE後，表的變化跟存儲引擎有關。
對於MyISAM， PTIMIZE TABLE 的工作原理如下：
· 如果表有已刪除的行或拆分行（split rows），修復該表。
· 如果未對索引頁面進行排序，對它們進行排序。
· 如果表的統計信息不是最新的（並且無法通過對索引進行排序來完成修復），更新它們。
對於InnoDB而言，PTIMIZE TABLE 的工作原理如下
對於InnoDB表， OPTIMIZE TABLE映射到ALTER TABLE ... FORCE（或者這樣翻譯：在InnoDB表中等價 ALTER TABLE ... FORCE），它重建表以更新索引統計信息並釋放聚簇索引中未使用的空間。當您在InnoDB表上運行時，它會顯示在OPTIMIZE TABLE的輸出中，如下所示：
mysql> OPTIMIZE TABLE foo;
+----------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+----------+----------+----------+-------------------------------------------------------------------+
| test.foo | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| test.foo | optimize | status | OK |
+----------+----------+----------+-------------------------------------------------------------------+
OPTIMIZE TABLE對InnoDB的普通表和分區表使用online DDL，從而減少了併發DML操作的停機時間。由OPTIMIZE TABLE觸發表的重建，並在ALTER TABLE ... FORCE的掩護下完成。僅在操作的準備階段和提交階段期間短暫地進行獨佔表鎖定。在準備階段，更新元數據並創建中間表。在提交階段，將提交表元數據更改。
OPTIMIZE TABLE 在以下條件下使用表複製方法重建表：
o 啓用old_alter_table系統變量時。
o 啓用mysqld --skip-new 選項時。
OPTIMIZE TABLE 對於包含FULLTEXT索引的InnoDB表不支持online DDL。而是使用複製表的方法。
InnoDB使用頁面分配方法存儲數據，並且不會像傳統存儲引擎（例如MyISAM）那樣受到碎片的影響。在考慮是否運行優化時，請考慮服務器將處理的事務的工作負載
o 預計會有一定程度的碎片化。 InnoDB僅填充93％的頁面，爲更新留出空間而無需拆分頁面。
o 刪除操作可能會留下空白，使頁面填充不如預期，這可能使得優化表格變得有價值。
當行有足夠的空間時，對行的更新通常會重寫同一頁面中的數據，具體取決於數據類型和行格式。見 Section 14.9.1.5, “How Compression Works for InnoDB Tables” 和 Section 14.11, “InnoDB Row Formats” 。
高併發工作負載可能會隨着時間的推移在索引中留下空白，因爲InnoDB通過其MVCC機制保留了相同數據的多個版本。見 Section 14.3, “InnoDB Multi-Versioning” 。
另外，對於innodb_file_per_table=1的InnoDB表，OPTIMIZE TABLE 會重組表和索引的物理存儲，將空閒空間釋放給操作系統。也就是說OPTIMIZE TABLE [tablename] 這種方式只適用於獨立表空間
關於OPTIMIZE TABLE，更多詳細細節參考https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html。感覺官方文檔相當詳細。
ALTER TABLE table_name ENGINE = Innodb;
這其實是一個NULL操作,表面上看什麼也不做,實際上重新整理碎片了.當執行優化操作時,實際執行的是一個空的 ALTER 命令,但是這個命令也會起到優化的作用,它會重建整個表,刪掉未使用的空白空間.
問題1：那麼是用OPTIMIZE TABLE 還是ALTER TABLE xxxx ENGINE= INNODB好呢？
其實對於InnoDB引擎，ALTER TABLE xxxx ENGINE= INNODB是執行了一個空的ALTER TABLE操作。而OPTIMIZE TABLE等價於ALTER TABLE ... FORCE。 參考上面描述，在有些情況下，OPTIMIZE TABLE 還是ALTER TABLE xxxx ENGINE= INNODB基本上是一樣的。但是在有些情況下，ALTER TABLE xxxx ENGINE= INNODB更好。例如old_alter_table系統變量沒有啓用等等。另外對於MyISAM類型表，使用ALTER TABLE xxxx ENGINE= INNODB是明顯要優於OPTIMIZE TABLE這種方法的。
問題2：ALTER TABLE xxxx ENGINE= INNODB 表上的索引碎片會整理麼
ALTER TABLE ENGINE= INNODB,會重新整理在聚簇索引上的數據和索引。如果你想用實驗驗證，可以對比執行該命令前後index_length的大小。