一、索引是什么？
1.MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构，即索引的本质是一种数据结构。
可以简单理解为：排好序的快速查找数据结构
详解：在数据之外，数据库系统还维护着满足特定查找算法的数据结构---索引，这些数据结构是以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级的查找算法。
左边是数据表，一共有两列七行数据，最左边存储的是内存地址。
为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在一定的复杂度内获取到相应数据，从而快速的检索出符合条件的记录。
二叉树弊端之一：二叉树很可能会发生两边不平衡的情况。
2.简单提一下MySQL索引的类型
B-TREE: (B:balance) 会自动根据两边的情况自动调节，使两端无限趋近于平衡状态。可以使性能最稳定。(myisam使用的方式)
B-TREE弊端：(插入/修改操作多时，B-TREE会不断调整平衡，消耗性能)从侧面说明了索引不是越多越好。
B+TREE:MySQL应用的索引结构
（下面会继续提到）
3.一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上（myi文件）
我们平常所说的索引，如果没有特别指明，都是指B树(多路搜索树，并不一定是二叉的)结构组织的索引。
其中聚集索引，次要索引，覆盖索引，复合索引，前缀索引，唯一索引默认都是使用B+树索引，统称索引。当然，除了B+树这种类型的索引之外，还有哈稀索引(hash index)等。
4.索引的优势与劣势
优势：1）类似大学图书馆建书目索引，提高数据检索的效率，降低数据库的IO成本
2）通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗
劣势：1）实际上索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录，所以索引列也是要占用空间的
2）虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件每次更新添加了索引列的字段，都会调整因为更新所带来的键值变化后的索引信息
3）索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句
二、索引类型
1.主键索引
设定为主键后，数据库会自动建立索引，Innodb存储引擎会默认将在主键上建立一个聚簇索引（下面会解释聚簇suoyin）。
2.单值索引
一个索引只包含单个列，一个表可以有多个单行索引
3.唯一索引
即建立unique约束时，会自动创建一个唯一索引
4.复合索引，即一个索引包含多个列。在数据库操作期间，复合索引比单值索引所需要的开销更小(对于相同的多个列建索引)
当表的行数远大于索引列的数目时可以使用复合索引。
三、索引结构
MySQL使用的索引结构为B+树索引，对我们Java开发工程师来说，我们无需关注太多类似于full-text全文索引、Hash索引、R-tree索引等其他索引，我们只需要关注最重要的两个：B-Tree索引和B+Tree索引。
1.首先我们先来讨论一个问题，文章刚开始时提到的图里索引结构为一个二叉树结构，那么为什么MySQL不使用那种二叉树作为索引结构呢？
如果用二叉查找树作为MySQL的索引结构，那假如我们有一百万条数据，这个树的深度可想而知，运气好第一层就找到了，运气不好，得进行多少次IO读写才能找到我们希望找到的数据？所以不能采用二叉树，因为它长得太高（深度太深）,导致I/O读写过于频繁。
如何解决？
二叉树又高又瘦，因为它的高是导致影响读写效率最主要的因素，那么非得用二叉树吗？我们可以采用多叉树啊，让它胖一点没关系，主要是矮啊！只要这个树深度够短，我们就可以通过极少的I/O读写来访问到我们要查找的数据，所以：B-树与B+树由此而生。
2.B-树
B-树也叫B树，‘-’只是一个符号，大家不要误会，所以提到BTree一般就是指的B-Tree。
每一个蓝色的关键字节点都又会去指向一个数据库的实际数据，只不过在这里没有体现，可以把这些蓝色的关键字节点理解为一个表中某字段的数据。
B-树的搜索，从根结点开始，对结点内的关键字（有序）序列进行二分查找，如果命中则结束，否则进入查询关键字所属范围的儿子结点；重复，直到所对应的儿子指针为空，或已经是叶子结点；
B-树的特性：
1）.关键字集合分布在整颗树中；
2）.任何一个关键字出现且只出现在一个结点中；
3）.搜索有可能在非叶子结点结束；
4）.其搜索性能等价于在关键字全集内做一次二分查找；
3.B+树（MySQL的索引结构）
B+树是应文件系统所需而产生的一种B树的变形树（文件的目录一级一级索引，只有最底层的叶子节点（文件）保存数据）非叶子节点只保存索引，不保存实际的数据，数据都保存在叶子节点中，这不就是文件系统文件的查找吗?
我们就举个文件查找的例子：有3个文件夹a、b、c， a包含b，b包含c，一个文件yang.c，a、b、c就是索引（存储在非叶子节点）， a、b、c只是要找到的yang.c的key，而实际的数据yang.c存储在叶子节点上。
所有的非叶子节点都可以看成索引部分！
非叶子节点（比如5，28，65）只是一个key（索引），实际的数据存在叶子节点上（5，8，9）才是真正的数据（指向数据库真实数据的指针）。
4.为什么说B+树比B-树更适合做数据库索引？
1）B+树的磁盘读写代价更低：B+树的内部节点并没有指向关键字具体信息的指针，因此其内部节点相对B树更小，如果把所有同一内部节点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多，一次性读入内存的需要查找的关键字也就越多，相对IO读写次数就降低了。（如果你看不懂这句话的意思，我负责给你解释：之前B-Tree是将真实数据存储到了非叶子节点中，现在B+Tree把存储真实数据的空间拿来去存储了引用，当利用索引查询时，需要从磁盘中加载这个节点到内存中去比较的时候，加载的需要查找的关键字也就比B-Tree要多，所以I/O读写次数自然就相对较低）
2）B+树的查询效率更加稳定：由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
3）由于B+树的数据都存储在叶子结点中，分支结点均为索引，方便扫库，只需要扫一遍叶子结点即可，但是B树因为其分支结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树更加适合在区间查询的情况，所以通常B+树用于数据库索引。
PS：我在知乎上看到有人是这样说的,我感觉说的也挺有道理的：
他们认为数据库索引采用B+树的主要原因是：B树在提高了IO性能的同时并没有解决元素遍历的我效率低下的问题，正是为了解决这个问题，B+树应用而生。B+树只需要去遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作或者说效率太低。
总结：所以要对查找的方式进行优化，熟悉的二分查找，二叉树可以把速度提升到O(log(n,2))，查询的瓶颈在于树的深度，最坏的情况要查找到二叉树的最深层，由于，每查找深一层，就要访问更深一层的索引文件。在多达数G的索引文件中，这将是很大的开销。所以，尽量把数据结构设计的更为‘矮胖’一点就可以减少访问的层数。在众多的解决方案中，B-/B+树很好的适合。B-树定义具体可以查阅，简而言之就是中间节点可以多余两个子节点，而且中间的元素可以是一个域。相比B-树，B+树的父节点也必须存在于子节点中，是其中最大或者最小元素，B+树的节点只存储索引key值，具体信息的地址存在于叶子节点的地址中。这就使以页为单位的索引中可以存放更多的节点。减少更多的I/O支出。因此，B+树成为了数据库比较优秀的数据结构，MySQL中MyIsAM和InnoDB都是采用的B+树结构。不同的是前者是非聚簇索引，后者主键是聚簇索引，所谓聚簇索引是物理地址连续存放的索引，在取区间的时候，查找速度非常快，但同样的，插入的速度也会受到影响而降低。非聚集索引的物理位置使用链表来进行存储。
四、在平时开发中，哪些情况需要建立索引，哪些情况不需要建立索引呢？
需要建立索引的情况
1.主键会自动建立唯一索引，且在Innodb存储引擎下创建聚簇索引。
2.频繁作为查询条件的字段应建立索引（where后面的子句）
3.查询中与其他表关联的字段，外键关系应建立索引。
如A 表关联 B 表：A join B 。 on 后面的连接条件 既 A 表查询 B 表的条件。所以 B 表被关联的字段建立索引能大大提高查询效率
因为在 join 中，join 左边的表会用每一个字段去遍历 B 表的所有的关联数据，相当于一个查询操作4.单键/组合索引的选择问题，who？(在高并发下倾向创建组合索引)
5.查询中排序和分组的字段，若通过索引去访问将大大提高排序速度。即group by 和 order by 后面的字段有索引大大提高效率。
不需要建立索引的情况
1.表中记录很少
2.经常进行增删改的表。
Why？建立索引会提高查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。
3.Where条件里用不到的字段不创建索引
4.数据重复且分布平均的表字段，因此应该只为最经常查询和最经常排序的数据列建立索引。注意，如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。
