MySQL分庫分表后總存儲變大了的原因是什么

本篇內(nèi)容介紹了“MySQL分庫分表后總存儲變大了的原因是什么”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

 1.背景
在完成一個分表項目后，發(fā)現(xiàn)分表的數(shù)據(jù)遷移后，新庫所需的存儲容量遠大于原本兩張表的大小。在做了一番查詢了解后，完成了優(yōu)化。

回過頭來，需要進一步了解下為什么會出現(xiàn)這樣的情況。

與標(biāo)題的問題的類似問題還有，為什么表數(shù)據(jù)內(nèi)容刪除了而表大小沒有變化。其本質(zhì)都是一樣的。

要回答這些問題，我們需要從mysql的索引模型談起。

2.InnoDB 的索引模型
在 MySQL 中，索引是在存儲引擎層實現(xiàn)的，所以并沒有統(tǒng)一的索引標(biāo)準(zhǔn)，即不同存儲引擎的索引的工作方式并不一樣。

而即使多個存儲引擎支持同一種類型的索引，其底層的實現(xiàn)也可能不同。由于 InnoDB 存儲引擎在 MySQL 數(shù)據(jù)庫中使用最為廣泛，所以接下來就以 InnoDB 為例，分析其中的索引模型。

在 InnoDB 中，表都是根據(jù)主鍵順序以索引的形式存放的，這種存儲方式的表稱為索引組織表。而InnoDB中，使用了 B+ 樹索引模型，所以數(shù)據(jù)都是存儲在 B+ 樹中的，每一個索引會對應(yīng)一顆B+樹。

假設(shè)，我們有一個主鍵列為 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

表中 R1~R5 的 (ID,k) 值分別為 (10,1)、(20,2)、(30,3)、(50,5) 和 (70,7)，索引id和索引k的B+樹的示例示意圖如下。

根據(jù)葉子節(jié)點的內(nèi)容，索引類型分為主鍵索引和非主鍵索引，主鍵索引的葉子節(jié)點存的是整行數(shù)據(jù)R1~R5，非主鍵索引的葉子節(jié)點內(nèi)容是主鍵的值。

從圖中可以看出，基于非主鍵索引的查詢需要多掃描一棵索引樹才能找到對應(yīng)的數(shù)據(jù)。提一句題外話，我們在應(yīng)用中應(yīng)該盡量使用主鍵查詢。

3.索引維護
B+ 樹為了維護索引有序性，在增刪改數(shù)據(jù)的時候需要做必要的維護。

假設(shè)，我們要刪掉 R4 這個記錄，InnoDB 引擎只會把 R4 這個記錄標(biāo)記為刪除。如果之后要再插入一個 ID 在 300 和 600 之間的記錄時，可能會復(fù)用這個位置。

如果刪掉了一個數(shù)據(jù)頁上的所有記錄，那么整個數(shù)據(jù)頁就能被復(fù)用了。進一步地，如果我們用 delete 命令把整個表的數(shù)據(jù)刪除呢？結(jié)果就是，這個表相關(guān)的所有的數(shù)據(jù)頁都會被標(biāo)記為可復(fù)用。

但是，無論如何，磁盤文件的大小并不會縮小。

這些被標(biāo)記為可復(fù)用，而并沒有實際被使用的空間，就是一些“存儲空洞”。

實際上，不止是刪除數(shù)據(jù)會造成空洞，插入數(shù)據(jù)也會。

以上圖為例，如果插入新的行 ID 值為 80，則只需要在 R5 的記錄后面插入一個新記錄。

如果新插入的 ID 值為 60，就相對麻煩了，需要邏輯上挪動后面的數(shù)據(jù)，空出位置。

而更糟的情況是，如果 R5 所在的數(shù)據(jù)頁已經(jīng)滿了，根據(jù) B+ 樹的算法，這時候需要申請一個新的數(shù)據(jù)頁，然后挪動部分數(shù)據(jù)過去。這個過程稱為頁分裂。在這種情況下，性能自然會受影響。

除了性能外，頁分裂操作還影響數(shù)據(jù)頁的利用率。原本放在一個頁的數(shù)據(jù)，現(xiàn)在分到兩個頁中，插入一條記錄竟然使得整體空間利用率降低大約 50%。

可以看到，由于 page 2 滿了，再插入一個 ID 是 60 的數(shù)據(jù)時，就不得不再申請一個新的頁面 page 3 來保存數(shù)據(jù)了。

頁分裂完成后，page 2 的末尾就留下了空洞（注意：實際上，可能不止 1 個記錄的位置是空洞）。

另外，更新索引上的值，可以理解為刪除一個舊的值，再插入一個新值。不難理解，這也是會造成空洞的。

因此，大量的增刪改之后的表，都是可能存在很大的“數(shù)據(jù)空洞”的。

因此，我們就能解釋，為什么分表后的總存儲變大了。

因為分表后，需要從老庫全量同步數(shù)據(jù)到新庫，數(shù)據(jù)同步平臺開啟多個線程進行同步，插入各個分表并不是按照遞增的順序插入的，因此，會產(chǎn)生巨量的“數(shù)據(jù)空洞”，造成存儲空間變大。

如果能夠把這些空洞去掉，就能達到收縮表空間的目的。而重建表就能達到這樣的目的。

4.重建表
如果我們手動重建一張表，可以新建一個與表 A 結(jié)構(gòu)相同的表 B，然后按照主鍵 ID 遞增的順序，把數(shù)據(jù)一行一行地（就是遞增地）從表 A 里讀出來再插入到表 B 中。由于表 B 是新建的表，所以表 A 主鍵索引上的空洞，在表 B 中就都不存在了。顯然地，表 B 的主鍵索引更緊湊，數(shù)據(jù)頁的利用率也更高。如果我們把表 B 作為臨時表，數(shù)據(jù)從表 A 導(dǎo)入表 B 的操作完成后，用表 B 替換 A，從效果上看，就起到了收縮表 A 空間的作用。

這里，你可以使用 alter table A engine=InnoDB 命令來重建表。在 MySQL 5.5 版本之前，這個命令的執(zhí)行流程跟我們前面描述的差不多，區(qū)別只是這個臨時表 B 不需要你自己創(chuàng)建，MySQL 會自動完成轉(zhuǎn)存數(shù)據(jù)、交換表名、刪除舊表的操作。顯然，花時間最多的步驟是往臨時表插入數(shù)據(jù)的過程，如果在這個過程中，有新的數(shù)據(jù)要寫入到表 A 的話，就會造成數(shù)據(jù)丟失。因此，在整個 DDL 過程中，表 A 中不能有更新。也就是說，這個 DDL 不是 Online 的。

MySQL 5.6 版本開始引入的 Online DDL，對這個操作流程做了優(yōu)化。

• 建立一個臨時文件，掃描表 A 主鍵的所有數(shù)據(jù)頁；

• 用數(shù)據(jù)頁中表 A 的記錄生成 B+ 樹，存儲到臨時文件中；

• 生成臨時文件的過程中，將所有對 A 的操作記錄在一個日志文件（row log）中；

• 臨時文件生成后，將日志文件中的操作應(yīng)用到臨時文件，得到一個邏輯數(shù)據(jù)上與表 A 相同的數(shù)據(jù)文件；(應(yīng)用row log的過程可能又回有頁分裂)

• 用臨時文件替換表 A 的數(shù)據(jù)文件。

可以看到，在這個過程中，由于日志文件記錄和重放操作這個功能的存在，這個方案在重建表的過程中，允許對表 A 做增刪改操作。這也就是 Online DDL 名字的來源。

需要補充說明的是，上述的這些重建方法都會掃描原表數(shù)據(jù)和構(gòu)建臨時文件。對于很大的表來說，這個操作是很消耗 IO 和 CPU 資源的。因此，如果是線上服務(wù)，你要很小心地控制操作時間。

optimize table、analyze table 和 alter table 這三種方式重建表的區(qū)別：

• 從 MySQL 5.6 版本開始，alter table t engine = InnoDB（也就是 recreate）默認的就是上面online DDL 的流程了；

• analyze table t 其實不是重建表，只是對表的索引信息做重新統(tǒng)計，沒有修改數(shù)據(jù)，這個過程中加了 MDL 讀鎖；

• optimize table t 等于 recreate+analyze。

“MySQL分庫分表后總存儲變大了的原因是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！