MySQL數據庫碎片化：隱患與解決策略
為什么我們經常說不建議使用簡單的 UUID 做 ID，當唯一索引，其實很大原因就是因為不規則的 UUID 會導致存儲碎片，接下來聊一聊 MySQL 為什么會有存儲碎片，影響大不大。
MySQL 中的數據庫表常會出現物理存儲碎片，特別是在頻繁執行插入、刪除和更新操作的情況下。這些操作會導致數據頁中部分空間未被有效利用，或者導致數據在物理存儲上排列不連續，進而形成碎片。
碎片的主要來源包括頻繁的 DML 操作，如插入（insert）、更新（update）、刪除（delete）。此外，使用可變長度字段（如 varchar 或 text）存儲數據時，如果更新導致字段長度變化，也可能產生碎片問題。
insert 導致的碎片
我們都了解，InnoDB 使用 B+樹索引結構來組織數據，通常按主鍵順序存儲。然而，當主鍵不是順序自增的情況下，比如使用 UUID，新插入的數據行可能會引發頁分裂現象。
頁分裂會導致數據分散存儲在磁盤的不同位置。新創建的頁可能與原始頁在物理存儲上相隔甚遠，導致數據在物理層面上不再連續，從而形成碎片。
頁分裂通常發生在向 B+樹索引插入新數據時，如果目標頁已滿，數據庫系統就需要為新數據騰出空間。
那究竟什么是 InnoDB 的頁分裂和頁合并呢，mark 一下。下一篇出。
update 導致的碎片
除了插入操作可能導致碎片外，更新操作同樣會產生碎片。特別是當更新操作導致數據行大小增加時，如果原始位置周圍沒有足夠的空間容納更新后的行，數據庫可能會將這行數據移動到數據文件的其他位置。這種情況會留下原始位置的空閑空間，導致碎片的產生。
delete 導致的碎片
最容易導致碎片的操作實際上是 delete 操作，尤其在 InnoDB 中更為明顯。執行 delete 后，InnoDB 僅僅是對數據行做了標記，而不是立即釋放相應的空間。這樣就可能導致數據頁中存在大量未被使用的空間，增加了數據在物理存儲上的分散程度，從而產生了碎片。
碎片的危害
表的碎片增多會導致數據在物理磁盤上存儲變得不連續，從而使得數據庫在查詢數據時需要進行更多的磁盤 I/O 操作，進而降低查詢效率。
此外，碎片化會導致數據庫實際占用的存儲空間比數據實際需要的空間大，造成磁盤空間的浪費，并可能影響緩存效率。
碎片化的數據還會增加備份文件的大小，同時使得備份和恢復的過程變得更為緩慢，因為這些操作也受到物理讀寫速度的影響。
因此，我們應該盡可能地減少碎片的產生，以提升數據庫的性能和效率。
如何避免碎片
- 使用連續自增的 ID 而不是 UUID，可以使新創建的對象在 B+樹的末尾插入，從而減少頁分裂的可能性。
- 對于固定長度的字符串，應該優先選擇 char 而不是 varchar，以減少存儲碎片的發生。
- 避免在高度變動的列上創建索引，因為這可能會頻繁觸發頁分裂。
- 使用 OPTIMIZE TABLE 命令可以重新組織表和索引的物理存儲，有效減少碎片并優化表的存儲和訪問速度。
