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

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

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

insert 導(dǎo)致的碎片

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

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

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

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

update 導(dǎo)致的碎片

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

delete 導(dǎo)致的碎片

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

碎片的危害

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

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

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

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

如何避免碎片

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