索引学习中…持续更新，欢迎指错
第一天学习：
B+tree mysql的索引形式
上图是B+树结构，在每个节点都会存放一个或多个值。用链表的形式把所有叶子节点连接起来，而且我们发现，父节点的元素都会在跟节点出现一次。当我们要查的数字是3时，我们会判断3比8小，那么就往它的左节点继续搜查，然后3在2~4的区间内，那我们就往他们之间的根节点继续搜查，如果在叶子节点找不到需要的值，因为叶子节点全部链起来的关系，他没必要返回上一层再次搜查，可以直接顺着链表往下走，这样大大提高了搜索效率。查询性能较稳定。
值得一提的是，在父结点中有几个元素，就有几个孩子。
哪些情况会使用到索引
在开发中索引应该更多用于查询操作，比如where语句在多条数据中按条件查出特定数据。
但是在select * from table的时候就没必要使用到索引了，因为遍历出来的行数是全部。加不加索引其实根本没影响。
上图中根据条件查找，在不加索引后遍历出来的行数是7，当你要查到的数据就在靠前位置还好，要是数据库几千条数据，你要找的那条信息在最后一行或者靠后位置，那么对资源和时间的消耗都不敢想。
同样的语句，在我添加索引之后，遍历行数只需一行，查找效率有了质的飞跃。
但是在使用索引的时候，使用了函数，索引会失效。
上图情况也会失效，因为上图中的情况相当于使用了cast（）函数
第二天学习
索引在什么情况下还会失效？
1 模糊查询的前导查询会失效
2.
如上图中所示，我建立了三个复合索引，分别是name，password，age这三列。
从上边三副图的三种情况可以发现，我建立了name password 和 age 的复合索引，去掉password和age的条件都可以调用索引，为什么去掉了name的条件索引就会失效呢？
再回到这张图：
原来建立了复合索引，每个列会根据顺序进行排序，前边所说到前导查询索引失效的推论也可以用在这里，按顺序进行查询，你要是不知道这个“1”，你就没办法索引到“2”“3”。（我自己的理解是：不知道这个1，就找不到复合索引的入口，就没办法根据索引找到往下的数据，比如说看电影，你找不到你在哪个包厅看电影，就找不到你手上捏着的观影票上的座位，也就没办法完成看电影这个操作）
*补充：当复合索引中某一列包含n个相同元素，那么区分度就会降低，索引查询效率就会变低，也就是我们在javaweb开发时，如果多个用户昵称一样，从数据库中根据他的昵称查找这个用户的效率就会降低。（看到这我才知道，为啥开发时为啥总是把id作为查询的条件：第一，id是默认建立索引的。第二个，id自增，不会出现区分度降低的情况，保证了查询效率）
索引排序问题 desc asc
在进行排序的时候，他没有根据索引进行排序。这样的排序效率显然降低。所以要进行数据库语句的优化，使得按照索引排序（具体优化策略我还不知道，后序补上）
*补充：如果要进行排序，可以直接用redis语句在redis进行排序（zrangebyscore key start end withscores），这是一个提高效率的排序办法。
索引下推 using index condition
索引下推的概念是在mysql5.6开始引用的，为了提高查询效率：
我们在进行and查询时，可能会碰到extra的值时using index condition的情况
索引下推是怎么提高查询效率的呢，如果没有索引下推的情况，那么按上图中的sql语句查询的过程是这样的：先查到满足索引为2的索引，回表查询出满足条件的数据，再找到满足年龄大于2的用户数据
索引下推：先查到满足索引为2的索引，直接找到满足年龄大于2的用户数据。
从字面上就能看出省掉了回表查询的步骤，效率提高。
第三天学习
or语句中的索引失效
<> 不等于语句的优化
当我们where查询的条件即便加了索引，索引也会失效。
索引对锁的影响
用户查询一行数据时，使用索引会把这列数据锁住，如果下一个用户来查询相同数据，就必须等待前一个用户把锁释放掉以后才能查询，大大降低了系统并发性。
优化查询
在针对比较长的数据时，我们可以找到规律，确保字符串前几位不重复的情况下，取字符串的前几位建立索引，加快索引效率。
慢查询日志
