mysql索引总结
mysql理解总结
操作系统背景：磁盘I/O是非常高昂代价的操作，计算机系统做了一些优化，当一次I/O时，不光会把当前磁盘地址的数据读取到内存中，而且会把相邻的数据也读取到内存缓冲区中，因为局部预读性原理告诉我们，当计算机访问一个地址的数据的时候，与其相邻的数据也会很快访问到。每一次I/O读取的数据我们称之为一页（Page）。也就是我们读取一页数据的时候，实际上才发生了一次I/O，这个理论对于索引的数据结构设计很有帮助。
Mysql的基本存储结构是页(记录都存在页里边)：
-
各个数据页可以组成一个双向链表
-
而每个数据页中的记录又可以组成一个单向链表
-
- 每个数据页都会为存储在它里边儿的记录生成一个页目录，在通过主键查找某条记录的时候可以在页目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录
- 以其他列(非主键)作为搜索条件：只能从最小记录开始依次遍历单链表中的每条记录。
所以说，如果我们写 select*fromuserwhereusername='Java3y'这样没有进行任何优化的sql语句，默认会这样做：
-
定位到记录所在的页
-
- 需要遍历双向链表，找到所在的页
-
从所在的页内中查找相应的记录
-
- 由于不是根据主键查询，只能遍历所在页的单链表了
索引将无序的数据变成有序(相对)：
要找到id为8的记录简要步骤：
很明显的是：没有用索引我们是需要遍历双向链表来定位对应的页，现在通过“目录”就可以很快地定位到对应的页上了！
其实底层结构就是B+树，B+树作为树的一种实现，能够让我们很快地查找出对应的记录。
上述的目录项其实就是索引B+树（主键索引），目录项里存放的是表示范围分组的索引的数据和对应不同范围的索引所在的下一级节点的目录（也叫作指针）叶子结点就是表数据组成的页
- B+树是一颗平衡树，如果我们对这颗树增删改的话，那肯定会破坏它的原有结构。
- 要维持平衡树，就必须做额外的工作。正因为这些额外的工作开销，导致索引会降低增删改的速度
图中浅蓝色的块，我们称之为一个磁盘，可以看到，每个磁盘块包含几个数据项（深蓝色）和指针（黄色）。如：磁盘块1包含数据17和数据35，包含指针P1,P2,P3，P1指向数据小于17的磁盘块，P2指向数据在17到35之间的数据所在磁盘块，P3指向数据大于35的数据所在的磁盘块。真实数据存在于叶子节点，即3，5，9，10，13，15，28，29，36，60，75，79，90，99 。 非叶子节点不存储真实数据，只存储指引搜索方向的数据项，如17、35并不真实存在于数据表中。
假设，我们要查找数据项29，那么我们首先会把磁盘块1由磁盘加载到内存中，此时进行了一次I/O，在内存中用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存计算时间由于非常短（对比于I/O）可以忽略不计，通过磁盘块1的P2指针的磁盘地址指向磁盘块3，由磁盘加载到内存，此时进行了第二次I/O，29在26和30之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，此时进行了第三次I/O，同时内存中计算二分查找找到29，查询结束。这一过程，一共进行了3次I/O。在真实使用场景中，三层的B+树可以表示上百万的数据，如果上百万的数据查询只需要三次I/O，性能提高将会是巨大的。B+树就是一种索引数据结构，如果没有这样的索引，每个数据项发生一次I/O，那么成本将会大大提升。
B+树的一些性质：
- 如果数据项占的空间越小，数据项的数量越多，树的高度也就越低。这也就是为什么每个数据项，即索引字段要尽量的小，比如int占4个字节，要比bigint的8个字节小一半。这也是为什么B+树要求把真实数据放在叶子节点内而不是内层节点内，一旦放到内层节点内，磁盘块的数据项会大幅度的下降，导致树层级的增高。
- B+树的数据项是复合性数据结构，比如（name，age，gender）的时候，B+树是按照从左到右的顺序来建立搜索树的，比如当（小张，22，女）这样的数据来检索的时候，B+树会优先比较name来确定下一步的搜索方向，如果name相同再依次比较age和gender，最后得到检索的数据。但是，当（22，女）这样没有name的数据来的时候，B+树就不知道下一步该查哪个节点，因为建立搜索树的时候，name就是第一个比较因子，必须根据name来搜索才知道下一步去哪里查询。比如，当（小张，男）这样的数据来检索时，B+树就可以根据name来指定搜索方向，但下一字段age缺失，所以只能把名字是“小张”的所有数据都找到，然后再匹配性别是“男”的数据了。这个是非常重要的一条性质，即索引的最左匹配特性。
哈希索引
哈希索引就是采用一定的哈希算法，把键值换算成新的哈希值，检索时不需要类似B+树那样从根节点到叶子节点逐级查找，只需一次哈希算法即可立刻定位到相应的位置，速度非常快。
- 本质上就是把键值换算成新的哈希值，根据这个哈希值来定位。
哈希索引有好几个局限(根据他本质的原理可得)：
- 哈希索引也没办法利用索引完成排序
- 不支持最左匹配原则
- 在有大量重复键值情况下，哈希索引的效率也是极低的---->哈希碰撞问题。
- 不支持范围查询
聚集和非聚集索引
简单概括：
- 聚集索引就是以主键创建的索引
- 非聚集索引就是以非主键创建的索引
区别：
- 聚集索引在叶子节点存储的是表中的数据
- 非聚集索引在叶子节点存储的是主键和索引列
- 使用非聚集索引查询出数据时，拿到叶子上的主键再去查到想要查找的数据。(拿到主键再查找这个过程叫做回表)
非聚集索引在建立的时候也未必是单列的，可以多个列来创建索引。
- 此时就涉及到了哪个列会走索引，哪个列不走索引的问题了(最左匹配原则-->后面有说)
- 创建多个单列(非聚集)索引的时候，会生成多个索引树(所以过多创建索引会占用磁盘空间)
- 覆盖索引就是把要查询出的列和索引是对应的，不做回表操作！
索引最左匹配原则
- 如果是联合索引，那么key也由多个列组成，同时，索引只能用于查找key是否存在（相等），遇到范围查询
(>、<、between、like左匹配)等就不能进一步匹配了，后续退化为线性查找。 - 因此，列的排列顺序决定了可命中索引的列数。
例子：
- 如有索引
(a,b,c,d)，查询条件a=1andb=2andc>3andd=4，则会在每个节点依次命中a、b、c，无法命中d。(c已经是范围查询了，d肯定是排不了序了) - a = 1 AND b = 2 AND c > 3 AND d = 4，如果建立 （a,b,c,d）顺序的索引，d是用不到索引的，如果建立（a,b,d,c）的索引，则都可以用到，a,b,d的顺序可以任意调整。
- 如有索引
(a,b,c,d)，查询条件c>3andb=2anda=1andd<4与a=1andc>3andb=2andd<4等顺序都是可以的，MySQL会自动优化为a=1andb=2andc>3andd<4，依次命中a、b、c。
不需要考虑=、in等的顺序，mysql会自动优化这些条件的顺序，以匹配尽可能多的索引列。
索引优化
- 索引不会包含有NULL值的列：只要列中包含有NULL值，都将不会被包含在索引中，组合索引中只要有一列有NULL值，那么这一列对于此条组合索引就是无效的。所以我们在数据库设计时，不要让索引字段的默认值为NULL。
- 使用短索引：假设，如果有一个数据类型为CHAR(255)的列，在前10个或20个字符内，绝大部分数据的值是唯一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省I/O操作（索引树每一个磁盘数据项可以容纳更多的数据，高度降低，当然降低了I/O次数）。
- 索引列排序：MySQL查询只使用一个索引，因此如果WHERE子句中已经使用了索引的话，那么ORDER BY中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下，不要使用排序操作；尽量不要包含多个列的排序，如果需要，最好给这些列也创建组合索引。
- LIKE "%aaaaa%"不会使用索引，但是LIKE "aaa%"却可以使用索引。
- 不要在索引列上进行运算：在建立索引的原则中，提到了索引列不能进行运算