1.索引的本质？
1)定义：数据库索引，是数据库管理系统(DBMS)中一个排序的数据结构，以协助快速查询、更新数据库表中数据。 这个定义类似于我们书中的目录 聚集索引(聚簇索引)
2）索引类型
在 InnoDB 里面，索引类型有三种，普通索引、唯一索引(主键索引是特殊的唯一索引)、全文索引。 普通(Normal):也叫非唯一索引，是最普通的索引，没有任何的限制。 唯一(Unique):唯一索引要求键值不能重复。另外需要注意的是，主键索引是一种特殊的唯一索引，它还多了一个限制条件，要求键值不能为空。主键索引用 primay key创建。 全文(Fulltext):针对比较大的数据，比如我们存放的是消息内容，有几 KB 的数据的这种情况，如果要解决 like 查询效率低的问题，可以创建全文索引。只有文本类型的字段才可以创建全文索引，比如 char、varchar、text。
2.索引存储模型推演
1）二分查找
我们知道索引是一个排序的数据结构，那我们针对一个已经排好序的数据结构，我们一般用二分查找的效率是最高的。那我们用什么样的数据结构呢？
11）有序数组：它查询效率高，但缺点是更新的时候，要大量移动数据 22）链表：如果是单链表的话，使用二分查找，效率还是不高，这个时候我们就要想到 二分查找链表(二叉查找树)
2）二叉查找树(BST Binary Search Tree)
我们都知道二叉查找树最坏的查找情况是出现斜树，这个时候时间复杂度就会退化为O(logn),所以我们衍生出平衡的二叉查找树。
3）平衡二叉树(AVL Tree)
1.存储方式？
它应该存储三块的内容:第一个是索引的键值。比如我们在 id 上面创建了一个索引，我在用 where id =1 的条件查询的时候就会找到索引里面的 id 的这个键值。第二个是数据的磁盘地址，因为索引的作用就是去查找数据的存放的地址。第三个，因为是二叉树，它必须还要有左子节点和右子节点的引用，这样我们才能找到下一个节点。比如大于 26 的时候，走右边，到下一个树的节点，继续判断。
2.存储方式的问题？
MySQL 的存储结构分为 5 级:表空间、段、簇、页、行。其中最重要的就是页这个概念，往表中插入数据时，如果一个页面已经写完，产生一个新的叶页面。如果一个簇的所有的页面都被用完，会从当前页面所在段新分配一个簇。如果数据不是连续的，往已经写满的页中插入数据，会导致叶页面分裂。
我们明白了上面的这些知识之后，InnoDB 操作磁盘的最小的单位是一页(或者叫一个磁盘块)，大小是 16K(16384 字节)。我们用树的方式进行存储的时候，我们是将一个结点与一页进行对应，那这样做的缺点是什么呢？
1）空间浪费：如果我们一个节点只存一个键值+数据+引用，例如整形的字段，可能只用了十几个或者几十个字节，它远远达不到 16K 的容量，所以访问一个树节点，进行一次 IO 的时候，浪费了大量的空间。
2)IO次数变多：访问一个树节点，进行一次 IO ,这样就导致效率降低。上面的图，如果我要查找id=37，那么我就要3次磁盘io
3.如何解决问题？
第一个就是让每个节点存储更多的数据。第二个，节点上的关键字的数量越多，我们的指针数也越多，也就是意味着可以有更多的分叉(我们把它叫做“路数”)。这就引入了B树这个结构
4）B树
5）B+树(加强版多路平衡查找树)
1.特点：1)它的关键字的数量是跟路数相等的; 2)B+Tree 的根节点和枝节点中都不会存储数据，只有叶子节点才存储数据。搜索到关键字不会直接返回，会到最后一层的叶子节点。比如我们搜索 id=28，虽然在第一层直接命中了，但是全部的数据在叶子节点上面，所以我还要继续往下搜索，一直到叶子节点。3)B+Tree 的每个叶子节点增加了一个指向相邻叶子节点的指针，它的最后一个数据会指向下一个叶子节点的第一个数据，形成了一个有序链表的结构。4)它是根据左闭右开的区间 [ )来检索数据。
2. B+Tree 的数据搜寻过程:1)比如我们要查找 28，在根节点就找到了键值，但是因为它不是页子节点，所以会继续往下搜寻，28 是[28,66)的左闭右开的区间的临界值，所以会走中间的子节点，然后继续搜索，它又是[28,34)的左闭右开的区间的临界值，所以会走左边的子节点，最后在叶子节点上找到了需要的数据。2)第二个，如果是范围查询，比如要查询从 22 到 60 的数据，当找到 22 之后，只需要顺着节点和指针顺序遍历就可以一次性访问到所有的数据节点，这样就极大地提高了区间查询效率(不需要返回上层父节点重复遍历查找)。
3.总结一下，InnoDB 中的 B+Tree 的特点:1）它是 B Tree 的变种，B Tree 能解决的问题，它都能解决。B Tree 解决的两大问题是什么?(每个节点存储更多关键字;路数更多) 2）扫库、扫表能力更强(如果我们要对表进行全表扫描，只需要遍历叶子节点就可以了，不需要遍历整棵 B+Tree 拿到所有的数据) 3)B+Tree 的磁盘读写能力相对于 B Tree 来说更强(根节点和枝节点不保存数据区，所以一个节点可以保存更多的关键字，一次磁盘加载的关键字更多) 4)排序能力更强(因为叶子节点上有下一个数据区的指针，数据形成了链表) 5)效率更加稳定(B+Tree 永远是在叶子节点拿到数据，所以 IO 次数是稳定的)
6)hash索引
1.特点：1）它的时间复杂度是 O(1)，查询速度比较快。因为哈希索引里面的数据不是按顺序存储的，所以不能用于排序。2).我们在查询数据的时候要根据键值计算哈希码，所以它只能支持等值查询(= IN)，不支持范围查询(> < >= <= between and) 3).字段重复值很多的时候，会出现大量的哈希冲突(采用拉链法解决)，效率会降低。
2. InnoDB 可以在客户端创建一个索引，使用哈希索引吗?
我们在 Navicat 工具里面选择索引方法是哈希，但是它创建的还是 B+Tree 索引，这个不是我们可以手动控制的。InnoDB 内部使用哈希索引来实现自适应哈希索引特性,这个特性就是 对于一些热点数据页，InnoDB 会自动建立自适应 Hash 索引，也就是在 B+Tree 索引基础上建立 Hash 索引，这个过程对于客户端是不可控制的，隐式的。
3.B+Tree 落地形式
MySQL 是一个支持插件式存储引擎的数据库，B+Tree 落地形式在不同的存储引擎实现的方式也是不一样的。我们这里讨论.MyISAM和innodb,在具体的讨论中，我们分为主键索引和辅助索引
1)MyISAM
在MyISAM里，索引和数据是两个独立的文件。我们怎么根据索引找到数据呢？---》MyISAM 的 B+Tree 里面，叶子节点存储的是数据文件对应的磁盘地址。所以从索引文件.MYI 中找到键值后，会到数据文件.MYD 中获取相应的数据记录。
1.主键索引：
2.辅助索引：在 MyISAM 里面，辅助索引也在这个.MYI 文件里面。辅助索引跟主键索引存储和检索数据的方式是没有任何区别的，一样是在索引文件里面找到磁盘地址，然后到数据文件里面获取数据。
2）InnoDB
1.综述：InnoDB 只有一个文件(.ibd 文件)，那索引放在哪里呢?在 InnoDB 里面，它是以主键为索引来组织数据的存储的，所以索引文件和数据文件是同一个文件，都在.ibd 文件里面。
2.主键索引存储：在 InnoDB 的主键索引的叶子节点上，它直接存储了我们的数据。
3.聚集索引(聚簇索引)：就是索引键值的逻辑顺序跟表数据行的物理存储顺序是一致的。(比如字典的目录是按拼音排序的，内容也是按拼音排序的，按拼音排序的这种目录就叫聚集索引)
4.InnoDB中的聚集索引：主键索引是聚集索引，非主键都是非聚集索引。聚集索引叫一级索引，非聚集索引又叫二级索引
5.InnoDB中的非聚集索引的存储和检索：辅助索引存储的是辅助索引和主键值。如果使用辅助索引查询，会根据主键值在主键索引中查询，最终取得数据。比如我们用 name 索引查询 name= '青山'，它会在叶子节点找到主键值，也就是id=1，然后再到主键索引的叶子节点拿到数据。
6.如果一张表没有主键怎么办：1)如果我们定义了主键(PRIMARY KEY)，那么 InnoDB 会选择主键作为聚集索引。2)如果没有显式定义主键，则 InnoDB 会选择第一个不包含有 NULL 值的唯一索引作为主键索引。3)如果也没有这样的唯一索引，则 InnoDB 会选择内置 6 字节长的 ROWID 作为隐藏的聚集索引，它会随着行记录的写入而主键递增。
4. 索引使用原则
1)列的离散(sàn)度
1.离散度的公式:count(distinct(column_name)) : count(*)，列的全部不同值和所有数据行的比例。数据行数相同的情况下，分子越大，列的离散度就越高。简单来说，如果列的重复值越多，离散度就越低，重复值越少，离散度就越高。
2.特点:如果在 B+Tree 里面的重复值太多，MySQL 的优化器发现走索引跟使用全表扫描差不了多少的时候，就算建了索引，也不一定会走索引。
3.用法：建立索引，要使用离散度(选择度)更高的字段。
2）联合索引最左匹配
1.特点：联合索引在 B+Tree 中是复合的数据结构，它是按照从左到右的顺序来建立搜索树的(name 在左边，phone 在右边)。从这张图可以看出来，name 是有序的，phone 是无序的。当 name 相等的时候，phone 才是有序的。
2.说明：这个时候我们使用 where name= '青山' and phone = '136xx '去查询数据的时候，B+Tree 会优先比较 name 来确定下一步应该搜索的方向，往左还是往右。如果 name相同的时候再比较 phone。但是如果查询条件没有 name，就不知道第一步应该查哪个节点，因为建立搜索树的时候 name 是第一个比较因子，所以用不到索引。
3.如何创建联合索引：
1）错误的案例：
2）解释：当我们创建一个联合索引的时候，按照最左匹配原则，用左边的字段 name 去查询的时候，也能用到索引，相当于建立了两个联合索引(name),(name,phone)，所以第一个索引完全没必要。
3) MySQL 联合索引的最左匹配原则扩展：如果我们创建三个字段的索引 index(a,b,c)，相当于创建三个索引:index(a)，index(a,b)，index(a,b,c)。用 where b=? 和 where b=? and c=? 和 where a=? and c=?是不能使用到索引的。也就是说不能中断。
4）在建立联合索引的时候，如何安排索引内的字段顺序？1.第一原则是，如果通过调整顺序，可以少维护一个索引，那么这个顺序往往就是需要优先考虑采用的,如上文的例子 2.考虑的原则就是空间，例如上面举的例子，如果需要对phone，name，以及name，phone联合查询， 如果phone的字段比较大，那就建立(phone,name) 和name俩个索引，而不是（name，phone）和phone
3）覆盖索引
1.回表：非主键索引，我们先通过索引找到主键索引的键值，再通过主键值查出索引里面没有的数据，它比基于主键索引的查询多扫描了一棵索引树，这个过程就叫回表。
2.覆盖索引：在辅助索引里面，不管是单列索引还是联合索引，如果 select 的数据列只用从索引中就能够取得，不必从数据区中读取，这时候使用的索引就叫做覆盖索引，这样就避免了回表。
3.覆盖索引演示：
4.覆盖索引特点：减少了 IO 次数，减少了数据的访问量，可以大大地提升查询效率。
4）索引条件下推(ICP)
1.适用范围：适用于二级索引
2.目的:减少访问表的完整行的读数量从而减少 I/O 操作。
3.注意：索引的比较是在存储引擎进行的，数据记录的比较，是在 Server 层进行的。
4.特点：把在Server 数据记录的比较，下推到存储引擎上的索引的比较
5.实现：select * from employees where last_name='wang' and first_name LIKE '%zi' ; 的俩种执行方式。
1）根据联合索引查出所有姓 wang 的二级索引数据，然后回表，到主键索引上查询全部符合条件的数据(3 条数据)。然后返回给 Server 层，在 Server 层过滤出名字以zi 结尾的员工。也就是说当 first_name 的条件不能用于索引过滤时，Server 层不会把 first_name 的条件传递给存储引擎，所以读取了两条没有必要的记录。
2）根据联合索引查出所有姓 wang 的二级索引数据(3 个索引)，然后从二级索引中筛选出 first_name 以 zi 结尾的索引(1 个索引)，然后再回表，到主键索引上查询全部符合条件的数据(1 条数据)，返回给 Server 层。本质上减少了回表的次数！
很明显，第二种方式到主键索引上查询的数据更少。
5. 索引的创建与使用
1）.索引的创建
1.在用于 where 判断 order 排序和 join 的(on)字段上创建索引 2.索引的个数不要过多 ——浪费空间，更新变慢。 3.区分度低的字段，例如性别，不要建索引。——离散度太低，导致扫描行数过多。4.频繁更新的值，不要作为主键或者索引。——页分裂 5.组合索引把散列性高(区分度高)的值放在前面。 6.创建复合索引，而不是修改单列索引。7.字段长度较长，我们可以使用前缀索引 8.尽量使用递增的id作为主键--》如果不用，会引起B+树的频繁改变
补充：插入的时候，如果某个数据页已经满了，根据B+树的算法，这时候需要申请一个新的数据页，然后挪动部分数据过去。这个过程称为页分裂。当相邻两个页由于删除了数据，利用率很低之后，会将数据页做合并。合并的过程，可以认为是分裂过程的逆过程！所以我们很多时候会重建索引的原因就是在这！
2)什么时候用不到索引?
1.索引列上使用函数(replace\SUBSTR\CONCAT\sum count avg)、表达式、计算(+ - * /)
2.字符串不加引号，出现隐式转换
3.like 条件中前面带%------》过滤的开销太大，涉及到B树的结点匹配，所以无法使用索引。这个时候可以用全文索引。
4.负向查询：
1）NOT LIKE 不能:
2）!= (<>)和 NOT IN 在某些情况下可以:
3）注意：一个 SQL 语句是否使用索引，跟数据库版本、数据量、数据选择度都有关系。其实，用不用索引，最终都是优化器说了算。
4）mysql优化器是基于什么的优化器?基于 cost 开销(Cost Base Optimizer)，它不是基于规则(Rule-Based Optimizer)，也不是基于语义。怎么样开销小就怎么来。