MySQL学习笔记-3-索引

I、索引的一些基本概念

索引就是数据结构
索引是为了提高数据查询效率

例子：字典。里面的声母查询方式就是聚簇索引。偏旁部首就是二级索引，偏旁部首+笔画就是联合索引。

II、常见索引模型

模型	表列 B	场景	场景
哈希表	键-值（类比hashmap）	等值查询	不能范围查询
有序数组	按顺序存储，用二分法查询	静态存储引擎	查询效率高，更新效率低
搜索树	每个节点的左儿子小于父节点，父节点又小于右儿子	等值和范围查询	数高过高，读写磁盘次数过多

InnoDB使用B+Tree索引。
InnoDB的表结构：1.在InnoDB中，每一张表其实就是多个B+树，即一个主键索引树和多个非主键索引树。2.执行查询的效率，使用主键索引>使用非主键索引>不使用索引。3.如果不使用索引进行查询，则从主索引B+树的叶子节点进行遍历。

III、索引类型

索引	存储方式	区别
主键索引（聚簇索引）	叶子节点存的是整行的数据	只要搜索ID这个B+Tree即可拿到数据
非主键索引（二级索引）	叶子节点内容是主键的值	先搜索索引拿到主键值，再到主键索引树搜索一次

从性能和存储空间方面考量，推荐使用自增主键，就可以保证新的ID一定是在叶子节点最右边，不会影响前面的数据。

IV、B+Tree索引维护

一个数据页满了，按照B+Tree算法，新增加一个数据页，叫做页分裂，会导致性能下降。空间利用率降低大概50%。当相邻的两个数据页利用率很低的时候会做数据页合并，合并的过程是分裂过程的逆过程。

需要复习一下二叉树、红黑树、B+树等数据结构

V、覆盖索引、前缀索引和索引下推

1、覆盖索引：如果查询条件使用的是普通索引（或是联合索引的最左原则字段），查询结果是联合索引的字段或是主键，不用回表操作，直接返回结果，减少IO磁盘读写读取正行数据
2、最左前缀：联合索引的最左N个字段，也可以是字符串索引的最左M个字符（MYSQL做词法分析语法分析的时候是通过建立最左子树来建立语法树的，解析的过程也是从左到右所以遵循最左前缀的原则。）
3、联合索引：根据创建联合索引的顺序，以最左原则进行where检索，比如（age，name）以age=1 或 age= 1 and name=‘张三’可以使用索引，单以name=‘张三’ 不会使用索引，考虑到存储空间的问题，还请根据业务需求，将查找频繁的数据进行靠左创建索引。比如一个联合索引(a,b,c)，其实质是按a,b,c的顺序拼接成了一个二进制字节数组，索引记录是按该字节数组逐字节比较排序的，所以其是先按a排序，再按b排序，再按c排序的，至于其为什么是按最左前缀匹配的也就显而易见了。
4、索引下推：like 'hello%’and age >10 检索，MySQL5.6版本之前，会对匹配的数据进行回表查询。5.6版本后，会先过滤掉age<10的数据，再进行回表查询，减少回表率，提升检索速度。

VI、mysql军规

给表创建索引时，应该创建哪些索引，每个索引应该包含哪些字段，字段的顺序怎么排列，这个问题没有标准答案，需要根据具体的业务来做权衡。不过有些思路还是可供参考的：
1.既然是一个权衡问题，没有办法保证所有的查询都高效，那就要优先保证高频的查询高效，较低频次的查询也尽可能的使用到尽可能长的最左前缀索引。可以借助pt-query-digest来采样统计业务查询语句的访问频度，可能需要迭代几次才能确定联合索引的最终字段及其排序。
2.业务是在演进的，所以索引也是要随着业务演进的，并不是索引建好了就万事大吉了，业务发生变化时，我们需要重新审视当初建的索引是不是还依然高效，依然能满足业务需求。
3.业内流传的有一些mysql军规，其实这些并不是真正的军规，只是典型场景下的最佳实践。真正的军规其实就一条：高效的满足业务需求。比如有个军规规定一个表上的索引数不超过5个，但如果我们现在有一些历史数据表、历史日志表，我们很明确的知道这些表上不会再有数据写入了，但我们的查询需求很多也很多样化，那我们在这些表上的索引数能不能超过5个？当然是没有任何问题的。当然关于这份军规还是要认真看一下的，但看的重点不是去记住它，而是要弄明白每一条军规它为什么这么规定，它这样规定是基于什么考虑，适用的场景和前提是什么，这些都弄明白了，你记不记得住这些军规都无所谓了，因为你已经把它溶化到了你的血液中，具体到自己的具体业务时游刃有余将是必然。