mysql聚簇索引和非聚簇索引以及二级索引

聚簇索引：  ORANCLE 中的索引组织表;   

如何区分聚簇索引和非聚簇索引？这里有一个比喻，来自网络： 

举例来说明一下聚集索引和非聚集索引的区别： 

其实，我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。 

我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。 

如果您认识某个字，您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字，然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。 

我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。 

  聚簇：数据行和数据紧密的存储在一起     叶子页　vs　节点页     叶子页存数据，节点页存索引。

innodb的聚簇索引实际上是在同一个结构中保存了btree索引和数据行。

INNODB通过主键列来索引数据。没有定义，INNODB会选择一个唯一的非空索引列代替。如果没有这样的索引，会选择第一个非空的唯一索引代替，如果没有非空唯一索引，Innodb会隐式定义一个6字节的rowid主键来作为聚集索引。innodb只聚集在同一个页面中的记录，包含相邻键值的页面可能会相距甚远。（物理位置）

聚簇索引：

  ORANCLE 中的索引组织表;

他的数据实际上存放的索引的叶子页中。    聚簇：数据行和数据紧密的存储在一起。                         叶子页　vs　节点页     叶子页存数据，节点页存索引。

innodb的聚簇索引实际上是在同一个结构中保存了btree索引和数据行。

INNODB通过主键列来索引数据。没有定义，INNODB会选择一个唯一的非空索引列代替。如果没有这样的索引，InnoDB会隐式定义一个主键。

聚集索引的缺点：

　　A：聚簇数据最大限度地提高了IO密集型应用的性能，但如果数据全部放在内存中，则访问的顺序就没有那么重要了，聚集索引也没有什么优势了

　　B：插入速度严重依赖于插入顺序，按照主键的顺序插入是加载数据到innodb表中速度最快的方式，但如果不是按照主键顺序加载数据，那么在加载完成后最好使用optimize table命令重新组织一下表 。                                     optimize table account;

　　C：更新聚集索引列的代价很高，因为会强制innodb将每个被更新的行移动到新的位置

　　D：基于聚集索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临页分裂的问题，当行的主键值要求必须将这一行插入到某个已满的页中时，存储引擎会将该页分裂成两个页面来容纳该行，这就是一次页分裂操作，页分裂会导致表占用更多的磁盘空间

　　E：聚集索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致数据存储不连续的时候

　　F：二级索引可能比想象的更大，因为在二级索引的叶子节点包含了引用行的主键列。

　　G：二级索引访问需要两次索引查找，而不是一次

因为二级索引叶子节点中保存的不是指向行的物理位置的指针，而是行的主键值。这意味着通过二级索引查找行，存储引擎需要找到二级索引的叶子节点获得对应的主键值，然后根据这个主键值去聚集索引中查找对应的行，这里做了重复的工作，两次btree查找而不是一次，对于innodb，自适应哈希索引能减少这样的重复工作。

 

innodb和myisam物理存储的数据分布对比：

　　myisam：

　　是按照数据插入的顺序存储在磁盘上的，myisam中的主键索引和二级索引在结构上并没有什么不同，主键索引就是一个名为primary的唯一非空索引。MyISAM的非聚餐索引：数据和索引是分开存放的 

　　innodb：

　　因为innodb支持聚集索引，所以使用非常不同的方式存储同样的数据，innodb聚集索引包含了整个表的数据，而不是只有索引，因为在Innodb中，聚集索引就是表，所以不像myisam那样需要独立的行存储。聚集索引的每一个叶子节点都包含了主键值，事务ID，用于事务和MVCC的回滚指针以及所有剩余列的值，如果主键是一个列前缀索引，innodb也会包含完整的主键列和剩下的列的值。

　　还有一点和myisam不同的是，innodb的二级索引和聚集索引很不同，innodb二级索引的叶子节点中存储的不是行指针，而是主键值，并以此作为指向行的指针，这样的策略减少了当出现行移动或者数据页的分裂时二级索引的维护工作，使用主键值当做指针会让二级索引占用更多的空间，换来的好处是，innodb在移动行时无须更新二级索引中的这个指针。

InnoDB的聚簇索引： 数据和主键索引是存放在一起的，其他索引叶子结点存放的主键id。 

 

InnoDB的的二级索引的叶子节点存放的是KEY字段加主键值。因此，通过二级索引查询首先查到是主键值，然后InnoDB再根据查到的主键值通过主键索引找到相应的数据块。而MyISAM的二级索引叶子节点存放的还是列值与行号的组合，叶子节点中保存的是数据的物理地址。所以可以看出MYISAM的主键索引和二级索引没有任何区别，主键索引仅仅只是一个叫做PRIMARY的唯一、非空的索引，且MYISAM引擎中可以不设主键。

　

InnoDb 使用自增主键和非自增主键乱序值做主键区别

eg :用UUID做主键，因为新航的主键值不一定比之前插入的大，所以Innodb无法简单的总是把新行插入到索引最后，而是需要为新行寻找合适的位置，并且分配空间，这样会增加很多额外的工作，并导致数据分布不够优化。这将导致 大量的随机I/O。因为写入是乱序的，IoonDB不得不频繁的做页分裂操作，页分裂会导致移动大量的数据，一次插入最好啊需要修改三个页。 并且页会变的稀疏并且被不规则的填充，所以最终数据会有碎片。

顺序主键也可能会造成       ①主键上届热点 ②AUTON_INCREMENT锁机制

可以修改 innodb_autoinc_lock_mode 参数

网上关于二级索引的解释：

二级索引也是有两个字段的有序文件：

第一个字段是索引字段，有相同的数据类型，并且是数据文件中的非排序字段，

第二个字段可以是一个块指针也可以是记录指针。二级索引（也称为非聚簇索引）用于在二级键上搜索文件，二级索引的搜索键指定了一个顺序，这个顺序与文件的排序顺序不同。例如，对于图3.16所示的EMPLOYEE薪水册文件，可能用雇员标识符（EMP.ID）作为构建主索引的主键，而雇员的姓和名（EMP.LNAME和EMP.FNAME）可能用于构建二级索引。因此，用户产生的搜索操作可以通过雇员标识符（EMP.ID）或者雇员的名字（EMP.FNAME和EMP.LNAME）来访问记录。

网上关于二级索引的解释：

二级索引也是有两个字段的有序文件：

第一个字段是索引字段，有相同的数据类型，并且是数据文件中的非排序字段，

第二个字段可以是一个块指针也可以是记录指针。二级索引（也称为非聚簇索引）用于在二级键上搜索文件，二级索引的搜索键指定了一个顺序，这个顺序与文件的排序顺序不同。例如，对于图3.16所示的EMPLOYEE薪水册文件，可能用雇员标识符（EMP.ID）作为构建主索引的主键，而雇员的姓和名（EMP.LNAME和EMP.FNAME）可能用于构建二级索引。因此，用户产生的搜索操作可以通过雇员标识符（EMP.ID）或者雇员的名字（EMP.FNAME和EMP.LNAME）来访问记录。

选择索引

　　这里我们要引入两个比较难理解但很重要的概念：聚簇索引和非聚簇索引。这是索引的两种类型。在聚簇索引中，索引树的叶级页包含实际的数据：记录的索引顺序与物理顺序相同。在非聚簇索引中，叶级页指向表中的记录：记录的物理顺序与逻辑顺序没有必然的联系。

　　聚簇索引非常象目录表，目录表的顺序与实际的页码顺序是一致的。非聚簇索引则更象书的标准索引表，索引表中的顺序通常与实际的页码顺序是不一致的。一本书也许有多个索引。例如，它也许同时有主题索引和作者索引。同样，一个表可以有多个非聚簇索引。通常情况下，你使用的是聚簇索引，但是你应该对两种类型索引的优缺点都有所理解。

　　从建立了聚簇索引的表中取出数据要比建立了非聚簇索引的表快。当你需要取出一定范围内的数据时，用聚簇索引也比用非聚簇索引好。例如，假设你用一个表来记录访问者在你网点上的活动。如果你想取出在一定时间段内的登录信息，你应该对这个表的DATETIME（日期时间）型字段建立聚簇索引。假如你不仅想根据日期，而且想根据用户名从你的网点活动日志中取数据。在这种情况下，同时建立一个聚簇索引和非聚簇索引是有效的。你可以对日期时间字段建立聚簇索引，对用户名字段建立非聚簇索引。如果你发现你需要更多的索引方式，你可以增加更多的非聚簇索引。

　　但非聚簇索引需要大量的硬盘空间和内存。另外，虽然非聚簇索引可以提高从表中取数据的速度，它也会降低向表中插入和更新数据的速度。每当你改变了一个建立了非聚簇索引的表中的数据时，必须同时更新索引。因此你对一个表建立非聚簇索引时要慎重考虑。如果你预计一个表需要频繁地更新数据，那么不要对它建立太多非聚簇索引。另外，如果硬盘和内存空间有限，也应该限制使用非聚簇索引的数量。