索引是个好东西，从诞生就闪耀着智慧的光芒。索引的数据结构可以是hash表，有序数组，B树，B+数。mysql中如果数据库引擎是innodb
- hash表
hash表其实跟HashMap是一样的数据结构，我们可以根据索引值的hash找到桶的位置，然后添加到桶对应的链表中。缺点是，hash表对区间查询不兼容，因为桶的列表是无序的，对应的链表是无序的，那么查找【k,k+1】的数据就需要遍历整个数据结构。所以hash表对等值查询的场景，比如Memcached或其他nosql引擎
- 有序数组
在《数据结构和算法》章节，我们讲过有序数组，有序数组的缺点就是在插入删除的时候要做大量的数据复制，但是对于静态表很友好。比如静态数据存储引擎。
- b树
B树因为能保证顺序性，还能保证良好的插入删除操作性能，所以是一种比较优秀的索引类型。但是存在的问题就是，B树的层次特别的深，因为B树只能有两个子节点。对于大数据量的深度存储不友好。
- B+树
B+树因为可以有多个子节点，所以对深度来说比较友好，比如Innodb引擎，每个节点可以存储1200个子节点，那么只要4层，就可以存储1200^4个数据。而B树才能有16个数据。
图片引用的是丁齐老师的在极客时间中的mysql课程
在innodb中，所有的索引都是B+树，主键索引的叶子节点存储的是整行数据，所以查询到主键之后，就相当于查询到真正的数据，主键也叫聚簇索引。
非主键索引的子节点存储的是主键索引，查询到该索引就是查询到主键，然后根据主键查询数据，这个过程叫回表。然后非主键索引也叫二级索引。
索引维护
根据树结构的插入和删除，会带来子节点的合并和拆分，会造成损耗，而且索引维护也需要考虑空间复杂度。比如我们一个场景，存储用户信息的表，可以设置自增主键，也可以设置有业务语义的主键，但是自增主键能保证有序性，而业务主键可能没办法保证有序性，两外有个问题是，自增主键的内存占用更小。
什么情况下使用业务语义比较好呢，1:只有一个索引，2:该索引是唯一索引。这种典型的kv数据结构，可以使用业务逻辑字段做主键
索引为什么能提升查询效率
在执行查询的时候，执行引擎会优先使用索引，索引查找的时间比遍历的时间节省不少，除了查询索引本身带来的高效率，还有其他的手段来提高效率
- 覆盖索引
比如我们查询的语句时 select id from table t1 where t1.id>3 and t1.id <100.因为该条语句只查询了id这一个字段，而且id本身就是索引，那么只要查询索引的内容就能满足我们的查询需求，可以直接返回，不需要回表操作，这样就节省了很多时间。
再一个例子，如果我们需要在用户表里，根据身份证号查询用户姓名，那么如果这个查询特别高频，我们就可以维护一个联合索引，{"身份证“，”姓名“},这样就可以利用覆盖索引的特性，不需要回表操作，直接返回索引的内容
- 最左前缀原则
最左前缀原则表示的意思比较有意思，比如上面举到用户表有个联合索引{"name"，“age”}，如果我们查询张三的用户，其实也可以使用当前的联合索引，然后查询name为张三的用户。而且可以使用like语句，where name like zhang也可以用到当前索引。
所以在设计索引的时候，要非常关注查询语句的高频条件，比如 经常性按照name查找用户，或者性别，或者住址，就可以使用当前的name，age索引，但是如果你按照age字段查找其他信息，当前的联合索引就不能使用了。
- 索引下探
还是上面的索引{"name","id"},如果查询 name like zhang% and age =26的信息会有什么优化操作呢。按照覆盖索引的操作习惯，如果使用name = zhangsan and age = 26的时候，会直接返回索引的数据，不再进行回表，这个叫覆盖索引。
在mysql5.6之前，name like zhang% and age = 26的操作：
- 按照联合索引{"name","age"}查询name索引，
- 查询到主键id，然后回表
- 查询整条记录的age进行比较
- 如果满足，返回
- 不满足。继续
mysql5.6之后对该执行做了优化
- 按照联合索引{"name","age"}查询name索引
- 索引下探，查看索引其他的字段是否满足age的需求，
- 如果不满足，遍历下一个索引
- 如果满足，直接返回该索引数据
我们看到优化之后可以尽量用到索引的特性，而减少回表的次数。这就是mysql引擎做到的优化。我们在开发的过程中要充分利用到这些特性设计索引。
以上是我学习丁齐老师在极客时间的课程的总结。