什么是索引？
索引在MySQL中也叫做“键”，是存储引擎用于快速找到记录的一种数据结构。索引对于良好的性能
非常关键，尤其是当表中的数据量越来越大时，索引对于性能的影响愈发重要。
索引优化应该是对查询性能优化最有效的手段了。索引能够轻易将查询性能提高好几个数量级。
索引相当于字典的音序表，如果要查某个字，如果不使用音序表，则需要从几百页中逐页去查。
先引进聚簇索引和非聚簇索引的概念！ 我们平时在使用的Mysql中，使用下述语句 CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX index_name [USING index_type] ON tbl_name (index_col_name,...) index_col_name: col_name [(length)] [ASC | DESC] 创建的索引，如复合索引、前缀索引、唯一索引，都是属于非聚簇索引，在有的书籍中，又将其称为辅助索引(secondary index)。在后文中，我们称其为非聚簇索引，其数据结构为B+树。
非聚簇索引（辅助索引secondary index）- 复合索引、前缀索引、唯一索引。
聚簇索引（主键索引）-在Innodb中，Mysql中的数据是按照主键的顺序来存放的。那么聚簇索引就是按照每张表的主键来构造一颗B+树，叶子节点存放的就是整张表的行数据。
由于表里的数据只能按照一颗B+树排序，因此一张表只能有一个聚簇索引。 在Innodb中，聚簇索引默认就是主键索引。
那么，这个聚簇索引，在Mysql中是没有语句来另外生成的。
假设表没建主键呢？
回答是，如果没有主键，则按照下列规则来建聚簇索引。
没有主键时，会用一个唯一且不为空的索引列做为主键，成为此表的聚簇索引如果没有这样的索引，InnoDB会隐式定义一个主键来作为聚簇索引。
举例来说： 自增主键和uuid作为主键的区别么？
由于主键使用了聚簇索引，如果主键是自增id，那么对应的数据一定也是相邻地存放在磁盘上的。写入性能比较高。
如果是uuid的形式，频繁的插入会使innodb频繁地移动磁盘块，写入性能就比较低了。
索引原理介绍
索引的目的在于提高查询效率，与我们查阅图书所用的目录是一个道理：先定位到章，然后定位到该章下的一个小节，然后找到页数。
相似的例子还有：查字典，查火车车次，飞机航班等。
本质都是：通过不断地缩小想要获取数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件。
也就是说，有了这种索引机制，我们可以总是用同一种查找方式来锁定数据。
数据库也是一样，但显然要复杂的多，因为不仅面临着等值查询，还有范围查询(>、<、between、in)、模糊查询(like)、并集查询(or)等等。
数据库应该选择怎么样的方式来应对所有的问题呢？我们回想字典的例子，能不能把数据分成段，然后分段查询呢？
最简单的如果1000条数据，1到100分成第一段，101到200分成第二段，201到300分成第三段......这样查第250条数据。
只要找第三段就可以了，一下子去除了90%的无效数 据。但如果是1千万的记录呢，分成几段比较好？
稍有算法基础的同学会想到搜索树，其平均复杂度是lgN，具有不错的查询性能。
但这里我们忽略了一个关键的问题，复杂度模型是基于每次相同的操作成本来考虑的。
而数据库实现比较复杂，一方面数据是保存在磁盘上的，另外一方面为了提高性能。
每次又可以把部分数据读入内存来计算，因为我们知道访问磁盘的成本大概是访问内存的十万倍左右，所以简单的搜索树难以满足复杂的应用场景。
先来一张带主键的表，如下所示，pId是主键
| pId | name | birthday |
|---|---|---|
| 5 | zhangsan | 2016-10-02 |
| 8 | lisi | 2015-10-04 |
| 11 | wangwu | 2016-09-02 |
| 13 | zhaoliu | 2015-10-07 |
画出该表的结构图如下
如上图所示，分为上下两个部分，上半部分是由主键形成的B+树，下半部分就是磁盘上真实的数据！那么，当我们， 执行下面的语句
|
1
|
select * from table where pId=‘11‘ |
那么，执行过程如下
如上图所示，从根开始，经过3次查找，就可以找到真实数据。如果不使用索引，那就要在磁盘上，进行逐行扫描，直到找到数据位置。显然，使用索引速度会快。但是在写入数据的时候，需要维护这颗B+树的结构，因此写入性能会下降！
OK，接下来引入非聚簇索引!我们执行下面的语句
|
1
|
create index index_name on table(name); |
此时结构图如下所示
注意看，会根据你的索引字段生成一颗新的B+树。因此， 我们每加一个索引，就会增加表的体积， 占用磁盘存储空间。
然而，注意看叶子节点，非聚簇索引的叶子节点并不是真实数据，它的叶子节点依然是索引节点，存放的是该索引字段的值以及对应的主键索引(聚簇索引)。
如果我们执行下列语句
|
1
|
select * from table where name=‘lisi‘ |
此时结构图如下所示
通过上图红线可以看出，先从非聚簇索引树开始查找，然后找到聚簇索引后。根据聚簇索引，在聚簇索引的B+树上，找到完整的数据！
什么情况不去聚簇索引树上查询呢？
还记得我们的非聚簇索引树上存着该索引字段的值么。如果，此时我们执行下面的语句
|
1
|
select name from table where name=‘lisi‘ |
此时结构图如下
如上图红线所示，如果在非聚簇索引树上找到了想要的值，就不会去聚簇索引树上查询。
当执行select col from table where col = ?，col上有索引的时候，效率比执行select * from table where col = ? 速度快好几倍！
那么这个时候，我们执行了下述语句，又会发生什么呢？
|
1
|
create index index_birthday on table(birthday); |
此时结构图如下
看到了么，多加一个索引，就会多生成一颗非聚簇索引树。
原文：https://www.cnblogs.com/drizzle-xu/p/10418668.html