MySQL数据库碎片化 隐患与处置战略

为什么咱们经常说不倡导经常使用便捷的 UUID 做 ID，当惟一索引，其实很大要素就是由于不规定的 UUID 会造成存储碎片，接上去聊一聊 MySQL 为什么会有存储碎片，影响大不大。

MySQL 中的数据库表常会出现物理存储碎片，特意是在频繁口头拔出、删除和降级操作的状况下。这些操作会造成数据页中局部空间未被有效应用，或许造成数据在物理存储上陈列不延续，进而构成碎片。

insert 造成的碎片

咱们都了解，InnoDB 经常使用 B+树索引结构来组织数据，通常按主键顺序存储。但是，当主键不是顺序自增的状况下，比如经常使用 UUID，新拔出的数据行或许会引发页决裂现象。

页决裂会造成数据扩散存储在磁盘的不同位置。新创立的页或许与原始页在物理存储上相隔甚远，造成数据在物理层面上不再延续，从而构成碎片。

页决裂通常出当初向 B+树索引拔出新数据时，假设指标页已满，数据库系统就须要为新数据腾出空间。

update 造成的碎片

除了拔出操作或许造成碎片外，降级操作雷同会发生碎片。特意是当降级操作造成数据行大小参与时，假设原始位置周围没有足够的空间容纳降级后的行，数据库或许会将这行数据移动到数据文件的其余位置。这种状况会留下原始位置的闲暇空间，造成碎片的发生。

delete 造成的碎片

最容易造成碎片的操作实践上是 delete 操作，尤其在 InnoDB 中更为显著。口头 delete 后，InnoDB 仅仅是对数据行做了标志，而不是立刻监禁相应的空间。这样就或许造成数据页中存在少量未被经常使用的空间，参与了数据在物理存储上的扩散水平，从而发生了碎片。

碎片的危害

表的碎片增多会造成数据在物理磁盘上存储变得不延续，从而使得数据库在查问数据时须要启动更多的磁盘 I/O 操作，进而降落查问效率。

此外，碎片化会造成数据库实践占用的存储空间比数据实践须要的空间大，形成磁盘空间的糜费，并或许影响缓存效率。

碎片化的数据还会参与备份文件的大小，同时使得备份和复原的环节变得更为缓慢，由于这些操作也遭到物理读写速度的影响。

因此，咱们应该尽或许地缩小碎片的发生，以优化数据库的性能和效率。

如何防止碎片