1.2、索引 B+Tree 结构的特性：
①、B+Tree 只有叶子节点会存储真实的数据，非叶子节点只会存储索引字段值；
②、B+Tree的叶子节点之间使用 双向链表 链接，所以更加适合范围查询和排序；
2、索引的类型：
在平时创建的索引中，可以将索引大体分为两类：
①、聚簇索引(主键索引) ②、非聚簇索引(二级索引)
二级索引根据索引中的字段个数可以分为：
①、单字段索引 ②、联合索引 / 复合索引(多个字段组成的索引)
3、不同类型索引在磁盘中的B+Tree的存储结构：
3.1、聚簇索引：(主键索引)
聚簇索引：当表中创建了主键，默认就会生成主键索引；
聚簇索引的B+Tree索引结构中，非叶子节点中存储的是ID主键值，存储在叶子节点中的真实数据是具体的行记录； 结构图如下：
3.2、单字段索引：(二级索引)
单字段索引：手动创建的索引，由一个字段组成的索引；
单字段索引的B+Tree索引结构中，非叶子节点中存储的是索引字段值，存储在叶子节点中的数据部分是主键值。结构图如下：
3.3、联合索引：(二级索引)
联合索引：手动创建的索引，由多个字段组成的索引；
联合索引的B+Tree索引结构中，非叶子节点中存储的是多个索引字段值，存储在叶子节点中的数据部分是主键值。结构图如下：
4、回表：
什么是回表？
回表是发生在二级索引中的；在使用二级索引查询数据时，如果select 投影列中拥有 索引字段和主键 之外的字段时，此时就需要 回表；使用在二级索引树中查询到的 主键值 去主键索引树中查询具体的行记录，然后在具体行记录中取得最终的 select 投影列 数据。
4.1、举例说明：
数据表：t_user
字 段：id(主键)、name、age、address、sex
索 引：index( name, age ) 测试的这个索引是 联合索引，单字段索引也是一样的原理
Sql语句：selectname, age, address, sexfrom t_user where name=’黎明’ and age=18
上面的sql语句执行时，就会发生回表；具体执行步骤如下：
①、执行时，首先会使用到 联合索引 index( name, age )，在此索引树中查询时，最终在叶子节点中查询到数据，发现此时最终只能得到 name、age、id 三个字段的数据，发现 address、age 这两个字段的数据没有得到，所以只能再根据查询到主键值去主键索引树中查询；
②、拿着 id主键值 去主键索引树中查询具体的行记录，然后在行记录中取出select投影列需要的字段的数据，最后返回。
4.2、扩展：
根据上面举的例子可以知道什么时候会发生回表，但是发生回表就代表着 查询效率 会比较低下的，因为需要走两边索引树(二级索引树 + 主键索引树)；所以一般情况下需要避免回表的发生；怎么避免发生呢？这又涉及到了覆盖索引这个知识点。下面就来介绍下覆盖索引的知识。
5、覆盖索引：
覆盖索引：大白话就是 将select 的投影列字段全部放入到 索引中；
5.1、举例说明：
数据表：t_user
字 段：id(主键)、name、age、address、sex
索 引：index( name, age )
Sql语句：selectname, age, address, sexfrom t_user where name=’黎明’ and age=18
这个sql执行时，会发生回表；
发生回表的原因通过上面的解释应该也清楚了些，所以如果 将索引index( name, age )改为 *index( name, age, address, sex ) *后，在执行上面的sql 就 不会发生回表了，并且提高了查询效率， 这就是 覆盖索引。
但是，索引的创建及维护也是需要耗费代价的，并且这种代价也是随着索引中索引字段的个数增加而增加的，所以覆盖索引需要根据实际情况使用。
6、最左前缀原则：
说到索引的最左前缀原则，就必须说下索引长度这个概念了；
索引长度指的是 索引字段列的 前缀长度索引；
例如：name字段的长度设置为100，但是在以name设置索引时设置的索引长度为20；意思就是创建的索引中存储的索引key键值就是name字段值的前20长度的内容。
6.1、索引的最左前缀原则的两种情况：
①、索引字段的最左前缀原则；
②、联合索引的最左前缀原则；
6.2、索引字段的最左前缀原则：
根据 索引长度 应该就可以明白了 索引字段的最左前缀原则了；但还是举例说明下：
经常说的导致索引失效的情况之一： 模糊查询时 将 % 放在了索引字段的前面；导致失效的最终原因就是 不满足索引的最左前缀原则；
数据表：t_user
字 段：id(主键)、name、age、address、sex
索 引：index( name )
Sql语句：select name, age from t_user where name like ’%黎明 ’
上面这个 sql 语句执行时，并不会走 index(name) 索引查询，因为什么呢？不满足索引的最左前缀原则。
6.2、联合索引的最左前缀原则：
根据联合索引的B+Tree 存储结构可以知道其最左前缀原则是什么。
不太清楚也别着急，下面将会举例说明：
数据表：t_user
字 段：id(主键)、name、age、address、sex
索 引：index( name, age )
Sql语句：select id from t_user where name=’黎明’ and age=26
测试数据 如图：
根据上面的测试数据及联合索引可以得到 B+Tree存储结构图：
上面sql执行时索引树的搜索步骤：
①、首先是加载索引树的根节点(磁盘块1)，然后匹配根节点中的第一个索引字段的值，查询name值是“黎明”的数据，得到指向其子节点地址的指针p1；
②、然后根据指针p1 找到子节点所在的磁盘块，然后将磁盘块加载到内存中，然后接着查询name值是“黎明”的数据，得到指向其子节点(叶子节点)地址的指针p3；
③、然后根据p3指针找到name值是“黎明”的 所在叶子节点的磁盘块，然后将磁盘块中数据加载到内存中，然后再比较 age 为26的数据，最终找到name值是“黎明”并且age为26 的 id主键值，由于select 投影列 只有 id 主键值，所以不需要回表，直接返回结果集了。
注意：在联合索引中，当索引中前一个索引字段值相同时，后面紧挨着的索引字段的值是有序的，所以索引天然适合进行排序，无需自己再进行排序了，提升了查询效率。
根据 上面的索引树搜索过程，知道一开始是以索引中的第一个索引字段进行搜索的，最后在叶子节点中依次进行的索引字段值的匹配，这就是联合索引的最左前缀原则；
所以如果sql语句中的where 条件中没有使用到联合索引的第一个索引字段，则整个索引就失效了。
索引创建的准则：
1、考虑创建索引的表的读写情况：
对于写操作比较多的表，创建索引时，应该尽量保证 联合索引 尽可能的窄(窄： 索引字段个数尽可能少)，如果索引字段比较多的话，写数据时的索引维护比较麻烦。
所以说，能创建单字段索引就不创建联合索引。
2、避免冗余索引：
合理创建索引，避免冗余索引；
联合索引index(a, b, c)相当于 index(a)、index(a，b)、index(a，b，c)这三个索引，所以如果有 index(a, b, c)索引了，那么 index(a)、index(a，b)这两个索引就不用存在了，属于重复索引了。
3、对多表关联查询使用的连接键字段创建索引：
针对 多表关联 查询时，需要将连接键 字段创建索引； 例如：user 、role 两张表；
(一)、 select * from user a, role b wherea.name = b.name【普通连接查询】
需要在 role 表中创建 name 连接键的索引，user 不必创建 name 字段索引；
(二)、select * from user a left join role b ona.name = b.name【左外连接查询】
需要在 role 表中创建 name 连接键的索引，user 不必创建 name 字段索引；
4、明确字段的区分度：
提前估算出表中每个字段存储的值的区分度，尽量在区分度高的字段创建索引，区分度低的字段创建索引用处不大，并且还会多出索引维护的消耗。
区分度：字段值的不同的比例；例如性别字段只会有两种值，男或女，属于区分度低的字段。
5、保证索引的唯一性：
创建索引时，尽可能保证索引的唯一性，唯一性指的什么呢？
在查看SQL执行计划时，执行计划中 possible_keys 中展示的就是优化器采样估算后可能会使用到的索引，只有这里展示一个索引，并且与实际使用的索引一致时，这才是唯一性；如果此处展示了多个索引名称的话，说明没有保证索引的唯一性。
为什么要保证唯一性呢？
因为如果在执行一个SQL时，优化器是通过采样分析判断发现有两个索引都可以时，那么就会面临抉择，到底最终使用哪个索引呢；如果只有一个索引符合的话，优化器直接选择即可。所以如果可以使用的索引存在多个的话，那么优化器还需要通过额外的运算得到最终使用的索引的，那么这就会降低查询效率的。
6、创建联合索引时，索引字段怎么排序：
在联合索引中，怎么对索引字段进行排序？ 大白话就是 在联合索引中，哪些索引字段 放在最前面？
①、where 条件中常使用的字段 放到前面。
②、区分度高的字段放在前面，因为这样可以减少扫描 B+tree 中的叶块。
《高性能MySQL》一书中提到的一个经验法则：将选择性最高(区分度高)的列放到索引最前列。
7、SQL中，有等值查询和范围查询时，联合索引怎么创建？
当然是将等值查询的字段放在联合索引的前面，范围查询的放到联合索引的后面；
为什么这么设计呢？
因为依据索引的查询规则，在联合索引中，首先都是根据第一个索引字段查询符合要求的数据，然后再从符合要求的数据中筛选第二个索引字段符合的数据；如果第一个索引字段值不符合，则直接结束查询了，不会再去进行范围查询了；但是如果将范围查询字段放在联合索引的第一位的话，那么很大可能会查询到符合范围的数据，然后再从数据中筛选等值查询的字段值，如果等值查询的值不存在，那么前面范围查询所做的工作就白白浪费了；并且降低了查询效率。
8、单表索引数量建议：
建议：单张表中索引的数量不超过5个；单个索引中的索引字段个数不超过5个；
导致索引失效的SQL：
明明已经创建好了索引，但是SQL执行时通过执行计划发现没有走索引查询，为什么？
1、查看SQL的执行计划：
创建好索引后，一般会查看下SQL的执行计划，看看SQL执行时是否走了索引查询；
Mysql 数据库查看执行计划 参考： 使用explain分析SQL执行计划
Oracle 数据库查看执行计划 参考： Oracle通过执行计划查看查询语句是否使用索引
2、导致SQL执行时没走索引的原因：
2.1、优化器采样估算后不走索引：
可能数据库的优化器在进行采样估算时，发现走全表扫描更加合适；例如：表中数据量很小时，全表扫描和索引查询可能一样快，所以此时可能会直接进行全部扫描查询了。
