常见的碎片类型

·Segment Fragmentation:段产生了碎片；没有按照数据的顺序存储，或者在数据页之间有空的页

·Tablespace Fragmentation:表空间中存储的是非连续的文件系统块

·Table Fragmentation：表中数据不是按照主键的顺序存储的。或者表的页有大量空闲空间。比如，表定义成了堆表。 data is stored not following the primary key order (heap tables), or table pages have a significant amount of free space (heap tables or index tables).

·Index Fragmentation: 索引通常是按照索引的顺序(b-tree)或无序的(hash索引)。碎片表示索引中有空闲的索引页

·Row Fragmentation: 单个行跨越了多个页

局部性原则

虽然局部性原则通常与处理器和高速缓存访问模式有关，但它也适用于一般的数据访问。这一原则描述了两种数据访问模式：空间局部性和时间局部性。

时间局部性意味着最近被检索的数据更容易在短时间内被再次需要。空间局部性告诉我们，某种程度上相关的数据（接近）往往会被一起访问。如果你的数据是按照局部性原则组织的，那么数据访问将更有效率。

碎片是如何影响数据的局部性的？

表和索引的碎片化常常导致数据库页包含大量的空闲空间。这降低了将经常访问的数据存储在一起的概率，违背了时间局部性原则。

表碎片化也会影响到空间局部性，因为它将相关数据存储在不同的数据库页上。关于表空间和段碎片，现代存储系统倾向于减少这些类型的碎片的影响。

行碎片的情况则有些不同。通常有三种可能：不支持行碎片，通过行链支持（部分行有一个指向另一个页面的指针，该行在那里继续），或者只支持大数据类型。在最后一种情况下，Blobs通常被存储在一个单独的区域中。这种类型的分片可以提高性能和效率。

InnoDB的碎片

在InnoDB中，所有东西都是一个索引。主键很重要，因为它们定义了数据在表中的排序方式。这种设计的效果之一是没有因无序的数据而产生的碎片。但是我们仍然可以有由表页的空闲空间引起的碎片。

分裂或不分裂，是个问题

InnoDB将行存储在页中。一条新的记录会根据主键放在一个特定的页。但是，当一个页满了，会发生什么？InnoDB必须分配一个新的页来存储新的行。在这里，InnoDB是相当聪明的。大多数RDBMS执行页分割：创建一个新的页，并且将完整页的一半内容移到最近分配的页上，留下两个半满的页。InnoDB所做的是分析和插入模式，如果它是连续的，则创建一个页并将新行放在那里。这对于连续的主键插入是非常有效的。

插入不需要是纯粹连续，它们需要遵循一个方向：递增或递减。我们将不介绍内部原理；只是告诉你，每个索引离开页都有元数据来表明最近插入的方向，以及在它之后插入了多少行。

随机与顺序插入对碎片的影响

正如上面所解释的，InnoDB有一个聪明的方法来识别新行是否必须插入到一个空页中，或者是否有必要进行分页。这种方法对于顺序插入来说是非常有效的，因为它产生的额外页数量最少，而在传统上，这种方法对于非顺序插入（当主键是随机的或者未知的时候）被认为是有害的。

我们将回顾一下顺序和随机插入的过程，以了解行是如何被插入的。但首先，让我们看看一个空页的内容。最初，我们有一些元数据和用于新数据的空闲空间。

一旦我们开始向这个页插入数据，数据是否连续并不重要；页面将开始填充。

但是一旦低于1/16的空闲空间，就必须分配新的页面。如何分配和填充新的页面，取决于插入是顺序的还是随机的。对于顺序插入，我们有这样的模式：

新的数据被插入到新的叶子页中。但是对于随机插入，我们有一个不同的行为：

我们必须在这两个页面上保留空闲空间，因为我们不能假设新行将被插入的位置。

随着新行的插入，顺序插入将以低碎片化的方式继续：

但是，随机插入会发生什么？为了简单起见，我们假设主键是均匀分布的。

在这里我们看到一个有趣的现象，当碎片化程度较低时，新的插入可能会触发页分割，从而增加碎片化程度。但是一旦达到一定的碎片化水平，几乎所有的页面都会有足够的空闲空间来接受新的行而不进行拆分。直到达到阈值，新的拆分将再次发生。

这意味着，随机插入会导致暂时性的碎片化。

随机插入和删除

前面的案例涵盖了只插入数据的情况，但当删除数据时，会发生什么？通常情况下，我们有一些定期清除旧行的表。如果它们是按主键排序的，就不会有任何问题：空页将从索引表的开头被完全删除。

我们在这里看到的是，旧的行属于相同的页，一旦它们被移除，就有可能将该页返回到表空间。稍后，这个页面将被再次分配给新的行使用。

但是当插入和删除是随机的时候，会发生什么呢？删除也是随机的，这个假设是正确的，因为数据是随机分布的。

我们可以看到，只要删除和插入的行数大致相等，这种模式就不会明显增加（或减少）碎片。

随机插入和删除的理想情况是有足够的空间来插入新的行而不达到分裂点。

分裂的其他原因

有三个因素定义了碎片化的额外原因。上面一直在分析第一个：数据是如何插入的。另外两个是数据修改（更新）和数据删除（删除）。

当一个空字段被填入数据或一个varchar字段内容被一个较长的文本取代时，页面必须为这个额外的数据腾出空间。如果没有足够的空闲空间会怎样？InnoDB将把页面分成两个半满的页面。这就增加了碎片化的程度。为了避免这种情况，InnoDB为每个页面保留1/16的数据修改空间。这种保留是不考虑插入模式的。

如果你增加了许多行的大小，也就会产生碎片化。

那么删除会发生什么呢？删除会通过减少存储在受影响页上的记录数量来增加碎片化。为了解决这个问题，如果一个页面的利用率低于50%，InnoDB将查看相邻的页面（按照索引顺序），如果其中一个页面低于50%，它将把两个页面合并成一个。释放出来的空间不会返回到文件系统中，而是被新的页面重新使用。

碎片检测

目前，还没有简单的方法来测量页碎片。

测量页分裂

识别碎片化正在发生的一个间接方法是测量页分裂的数量。不幸的是，我们不可能测量在插入或更新一个特定的表时产生的分裂的数量。

关于InnoDB页分裂的全局统计数据被存储在information_schema.innodb_metrics中。

这些统计数据必须通过使用innodb_monitor_enable全局变量来启用。

InnoDB Ruby

使用一个名为InnoDB Ruby的外部开源工具可以分析InnoDB的结构。Jeremy Cole已经开发了这个工具，可以在这里访问：https://github.com/jeremycole/innodb_ruby

还有一个wiki页面，记录了程序的使用：https://github.com/jeremycole/innodb_ruby/wiki

为了获得一个特定表的碎片的概况，你可以使用以下命令：

innodb_space -f space-extents-illustrate

这条命令返回一个表空间的图形，使用不同的格式在每一页上显示空间分配。

减少碎片

一旦表出现碎片，减少碎片的唯一方法就是重建表。通过重建表来减少碎片的问题在于，随机插入会很快使表碎片化。由于新行是随机插入的，而碎片的减少会导致没有空闲空间来存放新行，因此碎片会很快出现。

重建表可能会在重建后不久导致碎片的大量增加，因为页面分裂会使我们几乎所有的页面都是半满的。

Innodb填充因子(Innodb_fill_factor)

理想情况下，如果我们执行随机插入，我们必须在全表重建后为新的插入分配足够的空间。有一个全局变量可以实现这个功能：innodb_fill_factor。

"innodb_fill_factor定义了在建立排序索引过程中，每个B树页面被填充的空间百分比，剩余的空间保留给未来的索引增长。例如，将innodb_fill_factor设置为80，则为每个B树页面保留20%的空间用于将来的索引增长。实际的百分比可能会有所不同。innodb_fill_factor设置被解释为一个提示，而不是硬性限制"。

这意味着，如果我们执行随机插入和删除，并且使用足够大的填充因子来重建表，以容纳清除前的所有插入，表将保持较低的碎片水平。