索引分类
1、普通索引
2、特殊键索引
2.1、主键索引：primary key
2.2、唯一索引：唯一键索引
3、联合索引
包含两个，或者两个以上列的索引
4、全文检索：用来搜索一段文章时效果最好
5、空间索引：很少用到
索引的实现方式
索引其实是一种存储结构，mysql数据库当中使用的InnerDB和MyISAM引擎都使用B+树来实现，这里就主要介绍B+树的实现方式。
B+树当中的非叶子节点中存储的关键码并不指向数据库对象的地址指针，非叶子节点保存的只是索引部分，所有的叶子节点在同一层，包含了所有的关键码和相应数据对象的地址指针，并且叶子节点按照关键码从小到大链接。
B+树当中保存两个头指针，一个是树的根节点，一个叶子节点的最小关键码，所以B+树有两种查询方式
1、从叶子节点的最小关键码开始，顺序遍历最后一层的链表
2、从根节点开始，如果非叶子节点的关键码等于搜索的给定值，并不会停止搜索，而是从当前非叶子节点开始向右遍历，一直查到叶子节点的关键码，不管查询是否成功，都将走完B+树的所有层。
关于B+树使用建议：
1、索引字段要尽量的小，通过上面我们了解到，当这颗树越矮，我们加载磁盘数据执行IO的次数也就越少，在我们数据量大小一定的情况下，假设数据量为N，每个磁盘上的数据项的数量为m, 整个树的高度h = log(m+1)N, 当m越大，h就越小，m = 磁盘块的大小/数据项的大小，在磁盘块大小一定的情况下，数据项越小，m的值就会越大，我们的查询速度也就越快，如果数据项降低到了1，整个B+树就会变成一个线性表。
2、最左使用原则。当我们在使用组合索引时，比如（name,age ,score）,在执行查询时，会先通过name来进行查询，然后找到name的区间后，在通过age进行定位，最后是score, 如果我们这个时候的查询条件只有age和score，那么第一步的查询就无法执行，因此就使用不到索引，当我们使用的是name和score来进行筛选时，第一步通过name定位到数据所在的区间，在这个区间范围内，使用普通查询来查询score满足情况的数据。
B-树，即B树
Col1是物理地址，为了加快Col2的查找，维护了右边的二叉树，每个节点当中包含索引键值和一个指向数据记录的物理地址的指针，这样就可以使用二叉树方式查找到索引所在位置，时间复杂度为O(log2n)
B-Tree当中每个节点包括了键值和键值对应的数据对象存放的地址指针，所以当我们搜索一个索引时，可以不需要查询到叶子节点，成功搜索的时间取决于关键码所在的层次和节点内关键码的数量。
其查找方法是，从根节点开始，可以顺序查找也可以二叉查找，查询关键字所在的位置，如果查询到某个节点的关键码和给定的数相同，查找成功直接返回，否则可以确定要查找的内容是在Ki 和Ki+1 之间，然后取对象指针Pi所指向的下一层开始查找，直到查找成功。
对比B-/+Tree
B-Tree当中，最多需要检索n个节点，每个节点的大小是磁盘的一页，每个节点只需要一次IO就可以全部读取进来，在B-Tree当中最多需要n-1次IO读取（根节点常驻内存）
B-Tree当中，同一键值不会出现多次，要么在非叶子节点上，要么在叶子节点上，而B+Tree的键值一定出现在叶子节点上，并且有可能在非叶子节点上存在的也有，会重复。
B-Tree因为索引出现的位置不确定，并且只能出现一次，所在在插入和删除都需要对树进行修改，明显其操作复杂度更高，而B+Tree虽然可能会重复，但是其插入和删除只操作叶子节点。
B-Tree的查询效率和键在树当中的位置有关，可能一次IO就查询出来，其最大的时间复杂度和B+Tree相同，但是最小复杂度为1，在根节点，B+Tree的复杂度和建立好的树的深度有关。
索引的使用规则：
1、使用区分度高的列，计算区分度方式count(distinct(col))/count(*)
表示的是字段不重复的比例，比如主键的话，区分度是1，像性别等这些类型的区分度在大数据当中，可能就是0。
2、索引数据不参与计算，这里的不参与计算其实是，在条件筛选时候，索引列尽量保持干净，将计算公式放在等到右侧，原因是索引采用的B+树数据结构当中保存的是索引列的原始值，并不是计算过后的值，如果我们将索引列计算后再去筛选的话，索引是失效的。
3、最左匹配原则，这个原则主要是用在组合索引当中，比如我们建立了组合索引（a,b,c）等于建立了索引（a,b,c）,（a,b），（a）。在进行条件筛选时，如果我们的筛选条件当中有a=0 and b =0，那么会自动使用组合索引，如果是b=0 and c =0,根据最左匹配原则并不会使用索引。此外，如果我们创建了组合索引（a,b,c,d）而我们的筛选条件是a =0 and b=0 and c >0 and d =0, 根据最左匹配原则，d将不会使用索引搜索，原因是，mysql会一直向右匹配，直到遇到(>, <,between, like)就会停止，上述当中如果我们索引的创建采用方式是（a,b,d ,c）c之前的可以自由组合排序，那么d就可以被使用到了。
索引的优点
1、索引要解决的根本问题其实就是查询速度，所以这个就是索引的最大优点
2、加快表与表之间的连接，特别是在数据库参数的完整性方面
3、使用索引时，可以使用优化隐藏器来提高系统性能
索引的缺点
1、索引占据一定的存储空间，导致空间浪费
2、在对数据进行增加，修改，删除操作时，也需要修改索引，增加了数据维护的成本。
关于聚集索引和非聚集索引
聚集索引和非聚集索引的根本区别就是：表记录的排列顺序和索引记录的排列顺序是否一致。
聚集索引：表记录的顺序和索引记录的顺序是一致的。
非聚集索引：指向的是记录的逻辑顺序，表中记录的物理顺序和索引记录的顺序是不一致的。
在介绍聚集索引和非聚集索引之前，先弄清楚这两个的区别到底是什么，贴出来一段结合实际场景当中的例子
其实，我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。
如果您认识某个字，您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字，然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。
通过以上例子，我们可以理解到什么是“聚集索引”和“非聚集索引”。进一步引申一下，我们可以很容易的理解：每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。
聚集索引对于那些经常要进行范围内的搜索是比较有效的，使用聚集索引搜索到包含的第一个值之后，直接往后移动一定的距离，就是我们想要查询的这个范围区间，同样，如果经常需要对某列进行排序，那么在该列上创建聚集索引也是比较合适的。
聚集索引和非聚集索引都是通过B+树来实现的，不同的是，聚集索引的叶子节点就是数据节点，而非聚集索引的叶子节点是索引节点，同时还包含了指向的数据块的地址。
那么聚集节点和非聚集节点分别适合哪些场景呢？
聚集节点：
1、查询的结果是个区间值
2、查询的结果返回某个区间的大量数值
3、依照索引创建标准，还要符合区分度高的列，才建议创建聚集索引
非聚集索引适合场景：
1、查询的结果返回的是少量的结果集