為什么我們經(jīng)常說不建議使用簡(jiǎn)單的 UUID 做 ID，當(dāng)唯一索引，其實(shí)很大原因就是因?yàn)椴灰?guī)則的 UUID 會(huì)導(dǎo)致存儲(chǔ)碎片，接下來聊一聊 MySQL 為什么會(huì)有存儲(chǔ)碎片，影響大不大。

MySQL 中的數(shù)據(jù)庫表常會(huì)出現(xiàn)物理存儲(chǔ)碎片，特別是在頻繁執(zhí)行插入、刪除和更新操作的情況下。這些操作會(huì)導(dǎo)致數(shù)據(jù)頁中部分空間未被有效利用，或者導(dǎo)致數(shù)據(jù)在物理存儲(chǔ)上排列不連續(xù)，進(jìn)而形成碎片。

碎片的主要來源包括頻繁的 DML 操作，如插入（insert）、更新（update）、刪除（delete）。此外，使用可變長(zhǎng)度字段（如 varchar 或 text）存儲(chǔ)數(shù)據(jù)時(shí)，如果更新導(dǎo)致字段長(zhǎng)度變化，也可能產(chǎn)生碎片問題。

insert 導(dǎo)致的碎片

我們都了解，InnoDB 使用 B+樹索引結(jié)構(gòu)來組織數(shù)據(jù)，通常按主鍵順序存儲(chǔ)。然而，當(dāng)主鍵不是順序自增的情況下，比如使用 UUID，新插入的數(shù)據(jù)行可能會(huì)引發(fā)頁分裂現(xiàn)象。

頁分裂會(huì)導(dǎo)致數(shù)據(jù)分散存儲(chǔ)在磁盤的不同位置。新創(chuàng)建的頁可能與原始頁在物理存儲(chǔ)上相隔甚遠(yuǎn)，導(dǎo)致數(shù)據(jù)在物理層面上不再連續(xù)，從而形成碎片。

頁分裂通常發(fā)生在向 B+樹索引插入新數(shù)據(jù)時(shí)，如果目標(biāo)頁已滿，數(shù)據(jù)庫系統(tǒng)就需要為新數(shù)據(jù)騰出空間。

那究竟什么是 InnoDB 的頁分裂和頁合并呢，mark 一下。下一篇出。

update 導(dǎo)致的碎片

除了插入操作可能導(dǎo)致碎片外，更新操作同樣會(huì)產(chǎn)生碎片。特別是當(dāng)更新操作導(dǎo)致數(shù)據(jù)行大小增加時(shí)，如果原始位置周圍沒有足夠的空間容納更新后的行，數(shù)據(jù)庫可能會(huì)將這行數(shù)據(jù)移動(dòng)到數(shù)據(jù)文件的其他位置。這種情況會(huì)留下原始位置的空閑空間，導(dǎo)致碎片的產(chǎn)生。

delete 導(dǎo)致的碎片

最容易導(dǎo)致碎片的操作實(shí)際上是 delete 操作，尤其在 InnoDB 中更為明顯。執(zhí)行 delete 后，InnoDB 僅僅是對(duì)數(shù)據(jù)行做了標(biāo)記，而不是立即釋放相應(yīng)的空間。這樣就可能導(dǎo)致數(shù)據(jù)頁中存在大量未被使用的空間，增加了數(shù)據(jù)在物理存儲(chǔ)上的分散程度，從而產(chǎn)生了碎片。

碎片的危害

表的碎片增多會(huì)導(dǎo)致數(shù)據(jù)在物理磁盤上存儲(chǔ)變得不連續(xù)，從而使得數(shù)據(jù)庫在查詢數(shù)據(jù)時(shí)需要進(jìn)行更多的磁盤 I/O 操作，進(jìn)而降低查詢效率。

此外，碎片化會(huì)導(dǎo)致數(shù)據(jù)庫實(shí)際占用的存儲(chǔ)空間比數(shù)據(jù)實(shí)際需要的空間大，造成磁盤空間的浪費(fèi)，并可能影響緩存效率。

碎片化的數(shù)據(jù)還會(huì)增加備份文件的大小，同時(shí)使得備份和恢復(fù)的過程變得更為緩慢，因?yàn)檫@些操作也受到物理讀寫速度的影響。

因此，我們應(yīng)該盡可能地減少碎片的產(chǎn)生，以提升數(shù)據(jù)庫的性能和效率。

如何避免碎片

1. 使用連續(xù)自增的 ID 而不是 UUID，可以使新創(chuàng)建的對(duì)象在 B+樹的末尾插入，從而減少頁分裂的可能性。
2. 對(duì)于固定長(zhǎng)度的字符串，應(yīng)該優(yōu)先選擇 char 而不是 varchar，以減少存儲(chǔ)碎片的發(fā)生。
3. 避免在高度變動(dòng)的列上創(chuàng)建索引，因?yàn)檫@可能會(huì)頻繁觸發(fā)頁分裂。
4. 使用 OPTIMIZE TABLE 命令可以重新組織表和索引的物理存儲(chǔ)，有效減少碎片并優(yōu)化表的存儲(chǔ)和訪問速度。