从一个实战案例了解索引

我们可以看到这有一个87万的表

没加索引之间执行
SELECT * from t_program WHERE code = ‘1a5712ef6a864ccca9313aedab1d8f01’
需要5秒左右

但是加上索引之后执行
SELECT * from t_program WHERE code = ‘1a5712ef6a864ccca9313aedab1d8f01’
速度优化了很多

索引原理揭秘

在揭秘索引的原理之前，我们先来了解什么是索引：
官方定义是：索引（Index）是帮助MySQL高效获取数据的数据结构，简
单来说，索引是一种数据结构。
按照生活场景来理解，我们以一本中华字典为例，这本字典非常厚，如果我
们要从字典里面找一个汉字是非常耗时的，所以在字典的首页，提供了根据
拼音和偏旁来查找，这个拼音或者偏旁就是这本字典的索引。
除了词典，生活中随处可见索引的例子，如火车站的车次表、图书的目录
等。它们的原理都是一样的，通过不断的缩小想要获得数据的范围来筛选出
最终想要的结果，同时把随机的事件变成顺序的事件，也就是我们总是通过
同一种查找方式来锁定数据。

索引数据结构设计

其实，数据结构的选择，无非就是时间复杂度的选择。
简单来说，就是通过通过最少的IO次数，从磁盘中检索到目标数据！所以索
引的实现本质上就是一个查找算法。
那么，我们需要找到一个最合适的数据结构来实现快速查找功能，最基本的
查询算法当然是顺序查找（linear search），这种复杂度为O(n)的算法在数
据量很大时显然是不合适的，除了顺序查找，在数据结构中还有很多选择
比如：
1.二叉查找树
2. 平衡二叉查找树
3. 红黑树
4.多路平衡查找树(B树)

多路平衡查找树(B Tree)

基于上述分析的问题，其实有一个核心的点在于树的深度。
有没有其他的数据结构能够减少树的深度？从而降低和磁盘IO的次数呢？
于是，我们找到另外一种多路平衡查找树，也就是我们熟知的B Tree（B代
表平衡）

B Tree的特点

分叉数（路数）永远比关键字数多1。比如我们画的这
棵树，每个节点存储两个关键字，那么就会有三个指针指向三个子节点（当
然肯定不只存3个这么少）！
分叉数越多，树的深度就会更少，这样一来，原本高高瘦瘦的二叉树就变成
了矮矮胖胖的样子，如下图所示。

B Tree的查找规则

比如我们要在这张表里面查找15。

15小于17，走左边。
15大于12，走右边。
在磁盘块7里面就找到了15。
20条数据，由于多路数减少了树的深度，所以只有了3次磁盘IO就找到了，
极大的减少了磁盘交互次数

B Tree的工作原理

插入场景

假设在Max Degree(路数)是3的的B Tree中，意味着一个节点只能有3个指
针，所以一个节点只能存储2个key。
假设我们插入1、2、3这三个key，那么这个时候需要通过分裂的方式来保持
B Tree的平衡，那么它的演变过程如下。

节点的排列规则需要满足平衡二叉树的基本规则（左子节点小于父节点，右
子节点大于父节点）！

B Tree的优点和缺点

我们上面描述的B Tree中的节点，在Mysql中代表的是Page页。
前面我们说过，Mysql为了更好的利用磁盘的预读能力，把一个Page页的大
小设置为16k，也就是一个节点（磁盘块）的大小是16K。也就是说在进行一
次磁盘IO时，会把一个节点（16K）的索引加载到内存中。
假设我们设置的一个表的索引字段类型是int，也就是4个字节，如果每个关
键字对应的数据区(data)也是4个字节

在不考虑子节点引用的情况下，那么在B Tree中，每个阶段大概能存储的关
键字数量是：
( 16 * 1024 ) / 4+4 = 2048 个关键字
在B Tree中，一共有2049路。对于二叉树来说，三层高度最多可以保存7个
关键字，而对于这种2001路的B树，三层高度能够保存的关键字数远远大于
二叉树，因此B Tree用来存储索引非常合适。

缺点

B Tree在做检索时，检索效率非常高，但是在做数据插入和删除时，会破坏
B Three本身的行知，所以为了保持B Tree的平衡，需要对节点进行分裂、
合并、转移等操作，而这个操作在节点数量较多的情况下性能影响较大。
所以这也是为什么我们在做索引的创建和索引更改时，性能较慢的原因！

加强版多路平衡查找树(B+Tree)

在Mysql的InnoDB引擎中，并没有使用B Tree作为索引的存储结构，而是使
用B+Tree！它的存储结构如下图所示。

B+Tree的优化

B树的路数和关键字的个数的关系不再成立了，数据检索规则采用的是
左闭合区间，路数和关键个数关系为1比1
B+Tree的根节点和枝节点中都不会存储数据，只有叶子节点才存储数
据，并且每个叶子节点都会增加一个指针指向响铃的叶子节点，形成一
个有序链表结构。
在这样的几个B+ Tree结构下，假设我们要检索x=1的数据，那么检索的规
则是：
取出跟磁盘块，加载1/26/66三个关键字。
x<=1，取出磁盘块2，加载1/10/20三个关键字。
x<=1，取出叶子节点，加载1/8/9三个关键字。此时已经达到了叶子
节点，命中1，所以只需要加载对应1的数据内容（或者内容地址）即
可！

B+Tree和Tree的区别

B+Tree 关键字的搜索采用的是左闭合区间，之所以采用左闭合区间是
因为他要最好的去支持自增id，这也是mysql的设计初衷。即，如果id =
1命中，会继续往下查找，直到找到叶子节点中的1。
B+Tree 根节点和支节点没有数据区，关键字对应的数据只保存在叶子
节点中。即只有叶子节点中的关键字数据区才会保存真正的数据内容或
者是内容的地址。而在B树种，如果根节点命中，则会直接返回数据。
在B+Tree中，叶子节点不会去保存子节点的引用。
B+Tree叶子节点是顺序排列的，并且相邻的节点具有顺序引用的关系，
如上图中叶子节点之间有指针相连接。

Mysql为什么选择B+Tree

它是B Tree的变种，B Tree能解决的问题，它都能解决。B Tree解决的
两大问题是什么？（每个节点存储更多关键字；路数更多）
扫库、扫表能力更强（如果我们要对表进行全表扫描，只需要遍历叶子
节点就可以了，不需要遍历整棵B+Tree拿到所有的数据）
B+Tree的磁盘读写能力相对于B Tree来说更强（根节点和枝节点不保存
数据区，所以一个节点可以保存更多的关键字，一次磁盘加载的关键字
更多）
排序能力更强（因为叶子节点上有下一个数据区的指针，数据形成了链
表）
效率更加稳定（B+Tree永远是在叶子节点拿到数据，所以IO次数是稳定
的）

B+Tree作为索引的数据结构带来的好处

由于在B+ Tree中，每个节点不存存储数据区，只需要存储键值+指针，使得
B+ Tree在每个节点存储的路数更多。
假设索引字段+指针大小一共是16个字节，那么一个Page页（一个节点）能
存储1000个这样的单元（键值+指针）。
假设一条记录是16bytes，一个叶子节点（一页）可以存储10条记录！
当数的深度是2的时候，就有1000^2个叶子节点，可存储的数据为1000 x
1000 x 10 =10000000（千万）

也就是说，在InnoDB中B+树的深度在3层左右，就能满足千万级别的数据存
储。

索引的类别

聚簇索引

所谓的聚簇索引，就是只索引键值的逻辑顺序和表数据行的物理存储顺序一
致。只有聚簇索引才会在叶子节点缓存表中的数据。

在InnoDB中，组织数据的方式就是用聚簇索引组织表（Clustered Index
Organize Table），所以一张表创建了主键索引，那么这个主键索引就是聚
集索引。

非聚簇索引

除了主键索引以外，其他索引均属于非聚簇索引，非聚簇索引的叶子节点不
会存储表数据，那么在这种情况下。
如果要查询一个非聚簇索引的字段，怎么去获取到数据的值呢？我们来看一
下非聚簇索引的存储结构。

从上面这个图可以看到，真正的数据仍然是保存到主键索引的叶子节点（这
也就是为什么InnoDB表必须要有主键的原因），而辅助索引的叶子节点的
数据区保存的是主键索引的关键字的值（非主键索引叶子节点的逻辑顺序和
磁盘顺序不一致）。
当我们要查询where name = '王五’时，先通过二级索引去B + Tree中找到
王五的叶子节点，拿到对应的主键值，也就是id=15。
接着在根据这个条件去主键索引中查找到叶子节点拿到数据（这里不能存储
磁盘地址，因为在数据insert和delete时，B+Tree的结构会发生变化）。
所以，从这个角度来说，因为主键索引比二级索引少扫描了一棵B+Tree（这
个动作叫做回表），它的速度相对会快一些。

什么是回表

如果语句是select * from T where k=5，即普通索引查询方式，则需要先搜索k索引树，得到ID
的值为500，再到ID索引树搜索一次。这个过程称为回表这样会多扫描一颗B+树

覆盖索引

索引上的信息足够满足查询请求不需要在回到主键索引上去取数据这种情况可以避免回表提升查询效率
如以下这种案例:
select k from T where k=5
此时假如 k是普通索引或者联合索引的话 k能直接获取到数据就不需要在回表查询

联合索引

创建语句

ALTER TABLE t_program ADD INDEX cpid_name_index(cp_id,name);

联合索引查询规则

联合索引最左前缀原则

1.比如name上建立索引 age上没所有如果where age = and name = 索引会失效
2.遇到范围查询会失效
3.根据名称和 age 建立索引，只要跟在顺序调换了没有问题如果只根据名称也没问题但是如果只根据age 缺少名称就有问题了
4.分组和排序最好也根据联合索引的最左前缀

为什么建立联合索引要满足最左前缀原则

https://blog.csdn.net/taoshihan/article/details/110945156
比如有个联合索引 (b,c,d)
在索引的排序上 , 是先按b排序 , 再按c排序 , 再按d排序

比如有如下数据:

a 是主键 , b c d创建了联合索引
生成的索引结构为:

看最后的叶子节点数据的排序 , 先按第一行b 排序 , 再按第二行 c 排序 , 最后按第三行 d排序 , 紫色部分是主键

查询的时候 , 先按a字段的查询 a相同的再按b的查询 b也相同的再按c的查询

这样的索引构建方式及存储结构，所以联合索引只能从多列索引的第一列开始查找。所以如果你的查找条件不包含b列如(c,d)、©、(d)是无法应用索引的，以及跨列也是无法完全用到索引如(b,d)，只会用到b列索引。

联合索引的使用规则

1.如果通过调整顺序可以少维护一个索引那么这个顺序往往就是需要优先考虑使用的
2.那么，如果既有联合查询，又有基于a、b各自的查询呢？查询条件里面只有b的语句，是无法使用(a,b)这个联合索引的，这时候你不得不维护另外一个索引，也就是说你需要同时维护(a,b)、 (b) 这两个索引。

索引下推

只适应二级索引减少了访问表的行数
ICP默认开启针对二级索引只能能把条件下推给存储引擎就会自动下推
在索引遍历过程中，对索引中包含的字段先做判断，过滤掉不符合条件的记录，减少回表次数。

索引使用的建议

因为索引对于改善查询性能的作用是巨大的，所以我们的目标是尽量使用索
引。

创建索引的建议

1、在用于where判断order排序和join的（on）、group by的字段上创建索
引
2、索引的个数不要过多。——浪费空间，更新变慢。
3、过长的字段，建立前缀索引
4、区分度低的字段，例如性别，不要建索引。——离散度太低，导致扫描行数过多。
5、频繁更新的值，不要作为主键或者索引。——B+树的平衡导致页分裂，影响效率！
6、随机无序的值，不建议作为索引，例如身份证、UUID。——无序，分裂
7、组合索引把散列性高（区分度高）的值放在前面
8、创建复合索引，而不是修改单列索引！

什么情况下会导致索引失效?

1.出现隐式转换

比如数据类型存储类型是varchar 查询的时候却是比如where code =1这样而不是 where = ‘1’

2.计算

比如where code = 1+2 这种情况

3. like %wang%查询

那为什么like wang%这种写法会执行索引呢？
首先，字符串的匹配是基于最左匹配规则来执行的，为什么是最左匹
配，其实是和 B+Tree 有些关系，索引树从左到右都是有顺序的。对于
索引中的关键字进行对比的时候，一定是从左往右以此对比，且不可跳
过。
为什么是最左匹配原则？这个其实很好理解。比如，我们要比较一个字
符串。michael 与 mic，我们肯定是先从第一个字符开始比较吧，第一
个相同后，再比较第二个字符，以此类推。所以要从左边开始，并且是
不能跳过的。SQL 索引也是这样的。
–创建索引
ALTER TABLE user_innodb DROP INDEX comidx_name_phone;
ALTER TABLE user_innodb add INDEX comidx_name_phone
(name,phone);
–针对字符串列的where条件，分别添加引号和不添加引号
explain SELECT * FROM user_innodb where name = 136;
explain SELECT * FROM user_innodb where name = ‘136’;
explain select *from user_innodb where name like ‘%wang%’;
explain select *from user_innodb where name like ‘%wang’;
like %%这个要怎么优化才能走索引？
MySQL使用正则表达会使用索引吗
联合索引最左匹配原则那个例子，把name放到phone后面，查看
下，会不会走索引？
然后我们再来分析%，% 在前，就代表，我前面的内容不确定，对于不
确定的数据，索引无法比较，所以只能一个个的去比，这就相当于是全
表扫描了，全表扫描就没必要走索引，因此%写在前面是一定不会走索
引的。
如果%写在后面，由于前面的字符是确定的，所以可以通过索引来进行
匹配！

4.not like

explain select *from employees where last_name not like’wang’

5. 出现 != ,not in（）

在某些情况下可以使用到索引某些情况下不会

执行计划

执行计划是什么？

在前面一条select语句执行过程中有自己去看

结构

id

查询的序列编号由大到小排列 id 越大越先执行子查询最里层的子最先执行然后依次执行外层
关联查询时id 相同则按照顺序从上到下执行

select_type

对应的查询类型
PRIMARY
主查询
SUBQUERY
子查询
UNION
连接
UNION RESULT
合并结果集
SIMPLE
单表查询
DERIVER
派生
最终查询结果之前的临时结果

type

级别
System
特殊的 const类型针对于 MyISAM存储引擎的单表单记录查询
const
主键或者唯一索引的等值查询
eq_ref
多表查询中被驱动表通过唯一主键索引查询
ref
普通索引或者二级索引联合索引符合最左前缀，唯一索引弄了个 isnotnull

renge
基于索引的范围查询
ref_on_all
where name = x or name is null

index
遍历二级索引拿到数据

all
全表扫描

possible_keys

确认type 的访问方式有哪些索引可供选择

key

实际用到的索引

key_len

用到索引长度

ref

跟索引匹配的信息

rows

要扫描多少行才能返回

filtered

返回结果行数占需要结果行数的百分比只对 index和all有效

Extra

https://blog.csdn.net/ymb615ymb/article/details/123396914
Using index 没有回表
Using where 没有用B+树直接定位结果
Using index&Using where 没有回表且没有用B+树直接定位结果
Using index condition 部分where条件用B+树定位并过滤
Null 回表了且没用where条件过滤（可能是用B+树定位了，也可能是全表搜了）

join查询怎么用更好

select * from t1 straight_join t2 on (t1.a=t2.a); t1 是驱动表，t2是被驱动表。
1.有索引的话使用使用join语句，性能比强行拆成多个单表执行SQL语句的性能要好
2. 如果使用join语句的话，使用小表(先按照每个表的条件果过滤过滤完成之后计算参与join各个字段的总数据量数据量小的表就是小表)做驱动表
3. 如果使用Block Nested-Loop Join算法，扫描行数就会过多。尤其是在大表上的join操作，这
样可能要扫描被驱动表很多次，会占用大量的系统资源。所以这种join尽量不要用。
所以你在判断要不要使用join语句时，就是看explain结果里面，Extra字段里面有没有出现“Block
Nested Loop”字样。

mysql 关联查询流程

它对任何的关联都执行嵌套循环关联操作，即先在一个表中循环取出单条数据，然后在嵌套循环到下一个表中寻找匹配的行，依次下去，直到找到所有表中匹配的行为为止。然后根据各个表匹配的行，返回查询中需要的各个列。

Mysql索引底层结构解析相关推荐

MySQL索引底层实现原理 MyISAM非聚簇索引 vs. InnoDB聚簇索引
MySQL索引底层实现原理 MySQL官方对索引的定义为:索引(Index)是帮助MySQL高效获取数据的数据结构.提取句子主干,就可以得到索引的本质:索引是数据结构. 我们知道,数据库查询是数据库的 ...
深入理解 MySQL 索引底层原理
hi ,大家好,今天分享MySQL硬核知识,希望大家可以学习到真正的知识,慢慢积累,厚积薄发: 看完本文可以学到什么一步一步推导出 Mysql 索引的底层数据结构怎么分析回答技术选型问题一步 ...
Mysql 索引底层原理
一步一步推导出 Mysql 索引的底层数据结构. Mysql 作为互联网中非常热门的数据库,其底层的存储引擎和数据检索引擎的设计非常重要,尤其是 Mysql 数据的存储形式以及索引的设计,决定了 My ...
面试官：MySQL索引底层数据结构原理与性能调优，你能回答多少？
哈喽!大家好,我是小奇,一位不靠谱的程序员小奇打算以轻松幽默的对话方式来分享一些技术,如果你觉得通过小奇的文章学到了东西,那就给小奇一个赞吧文章持续更新,可以微信搜索[小奇JAVA面试]第一时间阅 ...
MYSQL索引底层原理
MYSQL索引底层原理 1. 索引的本质索引是帮助MYSQL高效获取数据的排好序的数据结构. 索引一般以文件形式存储在磁盘上. 2. 按索引的分类 2.1. 按字段约束分类 2.1.1. 普通索引 ...
MySQL索引底层数据结构
MySQL相信大家都不陌生,索引的日常使用应该也是比较频繁的,今天就聊一聊索引底层的数据结构; MySQL索引底层为什么使用B+树而不是二叉树;红黑树;B树? 索引:索引是帮助MySQL高效获取数据的 ...
Mysql——索引底层数据结构与Explain用法
Mysql--索引底层数据结构与Explain用法一.索引底层数据结构 1.Mysql不同引擎对应的数据结构 2.B+Tree数据结构 2.1. 二叉树 (Binary Search Trees) ...
助你进大厂，这些Mysql索引底层知识你是必须知道的。
前言上一篇总结了Mysql的锁机制,通过读者的反映和阅读量显示,总体还是不错的,感兴趣的可以阅读一下[大厂面试官必问的Mysql锁机制]. 写了那么多的Mysql文章,有读者问我是不是dba,工作真 ...
mysql索引数据结构图解_深入理解Mysql索引底层数据结构与算法
索引的定义:索引(Index)是帮助MySQL高效获取数据的数据结构. Q1:大家使用索引有没有想过这个问题?为什么索引能够帮助mysql高效获取数据?我一一给大家道来!在给大家讲之前,先更大家分享一 ...

Mysql索引底层结构解析