【MySQL系列相關】
1.背景
在完成一個分表項目後，發現分表的數據遷移後，新庫所需的存儲容量遠大於原本兩張表的大小。在做了一番查詢瞭解後，完成了優化。
回過頭來，需要進一步瞭解下爲什麼會出現這樣的情況。
與標題的問題的類似問題還有，爲什麼表數據內容刪除了而表大小沒有變化。其本質都是一樣的。
要回答這些問題，我們需要從mysql的索引模型談起。
2.InnoDB 的索引模型
由於 InnoDB 存儲引擎在 MySQL 數據庫中使用最爲廣泛，所以接下來就以 InnoDB 爲例，分析其中的索引模型。
在 InnoDB 中，表都是根據主鍵順序以索引的形式存放的，這種存儲方式的表稱爲索引組織表。而InnoDB中，使用了 B+ 樹索引模型，所以數據都是存儲在 B+ 樹中的，每一個索引會對應一顆B+樹。
假設，我們有一個主鍵列爲 ID 的表，表中有字段 k，並且在 k 上有索引，建表語句如下
CREATE TABLE `t` (
`id` int(11) NOT NULL,
`k` int(11) NOT NULL,
`name` varchar(16) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `k` (`k`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
爲什麼MySQL分庫分表後總存儲大小變大了？
表中 R1~R5 的 (ID,k) 值分別爲 (10,1)、(20,2)、(30,3)、(50,5) 和 (70,7)，索引id和索引k的B+樹的示例示意圖如下。
根據葉子節點的內容，索引類型分爲主鍵索引和非主鍵索引，主鍵索引的葉子節點存的是整行數據R1~R5，非主鍵索引的葉子節點內容是主鍵的值。
從圖中可以看出，基於非主鍵索引的查詢需要多掃描一棵索引樹才能找到對應的數據。
提一句題外話，我們在應用中應該儘量使用主鍵查詢。
3.索引維護
B+ 樹爲了維護索引有序性，在增刪改數據的時候需要做必要的維護。
假設，我們要刪掉 R4 這個記錄，InnoDB 引擎只會把 R4 這個記錄標記爲刪除。如果之後要再插入一個 ID 在 300 和 600 之間的記錄時，可能會複用這個位置。
如果刪掉了一個數據頁上的所有記錄，那麼整個數據頁就能被複用了。進一步地，如果我們用 delete 命令把整個表的數據刪除呢？結果就是，這個表相關的所有的數據頁都會被標記爲可複用。
但是，無論如何，磁盤文件的大小並不會縮小。
這些被標記爲可複用，而並沒有實際被使用的空間，就是一些“存儲空洞”。
爲什麼MySQL分庫分表後總存儲大小變大了？
實際上，不止是刪除數據會造成空洞，插入數據也會。
以上圖爲例，如果插入新的行 ID 值爲 80，則只需要在 R5 的記錄後面插入一個新記錄。
如果新插入的 ID 值爲 60，就相對麻煩了，需要邏輯上挪動後面的數據，空出位置。
而更糟的情況是，如果 R5 所在的數據頁已經滿了，根據 B+ 樹的算法，這時候需要申請一個新的數據頁，然後挪動部分數據過去。這個過程稱爲頁分裂。在這種情況下，性能自然會受影響。
除了性能外，頁分裂操作還影響數據頁的利用率。原本放在一個頁的數據，現在分到兩個頁中，插入一條記錄竟然使得整體空間利用率降低大約 50%。
可以看到，由於 page 2 滿了，再插入一個 ID 是 60 的數據時，就不得不再申請一個新的頁面 page 3 來保存數據了。
頁分裂完成後，page 2 的末尾就留下了空洞（注意：實際上，可能不止 1 個記錄的位置是空洞）。
另外，更新索引上的值，可以理解爲刪除一箇舊的值，再插入一個新值。不難理解，這也是會造成空洞的。
因此，大量的增刪改之後的表，都是可能存在很大的“數據空洞”的。
因此，我們就能解釋，爲什麼分表後的總存儲變大了。
因爲分表後，需要從老庫全量同步數據到新庫，數據同步平臺開啓多個線程進行同步，插入各個分表並不是按照遞增的順序插入的，因此，會產生巨量的“數據空洞”，造成存儲空間變大。
如果能夠把這些空洞去掉，就能達到收縮表空間的目的。而重建表就能達到這樣的目的。
4.重建表
如果我們手動重建一張表，可以新建一個與表 A 結構相同的表 B，然後按照主鍵 ID 遞增的順序，把數據一行一行地（就是遞增地）從表 A 裏讀出來再插入到表 B 中。由於表 B 是新建的表，所以表 A 主鍵索引上的空洞，在表 B 中就都不存在了。顯然地，表 B 的主鍵索引更緊湊，數據頁的利用率也更高。如果我們把表 B 作爲臨時表，數據從表 A 導入表 B 的操作完成後，用表 B 替換 A，從效果上看，就起到了收縮表 A 空間的作用。
這裏，你可以使用 alter table A engine=InnoDB 命令來重建表。在 MySQL 5.5 版本之前，這個命令的執行流程跟我們前面描述的差不多，區別只是這個臨時表 B 不需要你自己創建，MySQL 會自動完成轉存數據、交換表名、刪除舊錶的操作。顯然，花時間最多的步驟是往臨時表插入數據的過程，如果在這個過程中，有新的數據要寫入到表 A 的話，就會造成數據丟失。因此，在整個 DDL 過程中，表 A 中不能有更新。也就是說，這個 DDL 不是 Online 的。
MySQL 5.6 版本開始引入的 Online DDL，對這個操作流程做了優化。
建立一個臨時文件，掃描表 A 主鍵的所有數據頁；
用數據頁中表 A 的記錄生成 B+ 樹，存儲到臨時文件中；
生成臨時文件的過程中，將所有對 A 的操作記錄在一個日誌文件（row log）中；
臨時文件生成後，將日誌文件中的操作應用到臨時文件，得到一個邏輯數據上與表 A 相同的數據文件；(應用row log的過程可能又回有頁分裂)
用臨時文件替換表 A 的數據文件。
可以看到，在這個過程中，由於日誌文件記錄和重放操作這個功能的存在，這個方案在重建表的過程中，允許對錶 A 做增刪改操作。這也就是 Online DDL 名字的來源。
需要補充說明的是，上述的這些重建方法都會掃描原表數據和構建臨時文件。對於很大的表來說，這個操作是很消耗 IO 和 CPU 資源的。因此，如果是線上服務，你要很小心地控制操作時間。
optimize table、analyze table 和 alter table 這三種方式重建表的區別：
從 MySQL 5.6 版本開始，alter table t engine = InnoDB（也就是 recreate）默認的就是上面online DDL 的流程了；
analyze table t 其實不是重建表，只是對錶的索引信息做重新統計，沒有修改數據，這個過程中加了 MDL 讀鎖；
optimize table t 等於 recreate+analyze。
參考文獻：
《MySQL實戰45講》
《MySQL技術內幕》
看到這裏了，原創不易，點個贊吧，你最好看了～
掃碼關注我的公衆號“阿丸筆記”，第一時間獲取最新更新。同時可以免費獲取海量Java技術棧電子書、各個大廠面試題。
