索引碎片

个人理解：索引碎片针对的是索引页，而不是数据页，在搜索数据的时候会先加载数据库中的索引，不同的索引规模又不同的页数量，在正常情况下索引页是连续的，如果在聚集索引的情况下修改数据，那么修改后的数据要么大于要么小于原本数据，此时索引页就产生了空白或者超出原索引页容量；留出的空白会在插入数据时被重新利用，多出的部分就会重新分配数据页来存放超出的数据，而此时增加的数据页一般是不与原来的数据页连续，这就造成读盘时的延时。非聚集索引同样存在类似问题。对于非聚集索引，数据实体本身就是分散存储的。

内部碎片：

 指 当索引页没有用到最大量时就产生了内部碎片。虽然在一个有频繁数据插入的应用程序里这也许有帮助，然而设置一个fill factor（填充因子）会在索引页上留下空间，服务器内部碎片会导致索引尺寸增加，从而在返回需要的数据时要执行额外的读操作。这些额外的读操作会降低查询的性能
 
外部碎片;
 指 表中的数据被修改会产生碎片。当插入或更新表中数据时，表的对应聚簇索引和受影响的聚簇索引被修改。如果对索引的修改不能容纳到同一个页面中，就可能导致索引叶子页面分割。这样就会有一个新的叶子页面被添加，该页面包含原来页面中的部分信息（通常是一半），并且维持索引键中的逻辑顺序。但是该页面通常不是与原来页面相邻的。这就产生了逻辑关键字顺序和文件中的物理顺序不一致。
 

 ---外部碎片导致磁盘上的索引页面不连续,新的叶子页面和原始叶子页面离的很远,物理顺序和逻辑顺序不同.

什么是索引碎片?

　　由于表上有过度地插入、修改和删除操作，索引页被分成多块就形成了索引碎片，如果索引碎片严重，那扫描索引的时间就会变长，甚至导致索引不可用，因此数据检索操作就慢下来了。

　　有两种类型的索引碎片：内部碎片和外部碎片。

　　内部碎片：为了有效的利用内存，使内存产生更少的碎片，要对内存分页，内存以页为单位来使用，最后一页往往装不满，于是形成了内部碎片。

　　外部碎片：为了共享要分段，在段的换入换出时形成外部碎片，比如5K的段换出后，有一个4k的段进来放到原来5k的地方，于是形成1k的外部碎片。

对于mysql中的数据碎片，其实和我们删除数据是息息相关的，删除数据的时候必然会在数据文件中造成不连续的空白空间，对于少量的数据的删除，并不会产生多少的空白空间。如果在一段时间内的大量的删除操作，会使得这种留空的空间变得比存储列表内容所使用的空间更大。可能有人会说，我们向数据库中插入数据的时候，会不会在这些空白空间中插入数据呢？答案是会的。但是，它会造成一个后果，那就是数据的存储位置不连续，以及物理存储顺序与理论上的存储顺序不相同，这就比较麻烦了。

      按照数据碎片的大小来分，可以分为单行数据碎片和多行数据碎片。其实不仅仅会产生数据碎片，如果加了索引，还会产生索引碎片，这样会造成顺序的紊乱。由于MySQL的引擎的内部实现机制不同，在数据碎片的处理上也会不同。

         对于MyISAM来说，因为它的索引和数据以及表结构分为三个文件来存储，因此optimize可以整理数据文件，并且重新排序，这样因为数据碎片产生的性能问题会减少很多，直接使用【optimize table 表名】即可，但是此时也应该注意一些问题，由于该操作会锁住表，所以我们尽量定期整理一下碎片，在访问量小的时候来做这件事