对mysq索引的浅显理解

索引

为了加快查询速度我们在创建表的时候通常会添加索引，了解索引的结构，以及索引是怎么加快查询速度的，对我们准确使用索引以及面试都是有很大的帮助的。我们知道mysql的两个存储主流引擎innodb、myisam都是使用b+数存储索引的，那么我们不禁会有下面的疑问？

为什么不使用hash表？

我们知道数和hash都能提高查询的速度，为什么innodb、myisam选择了hash表，从hash表本身来说，hash表需要由一个优秀的hash算法才能使数据均匀的分布到hash表中，然而在实际的操作中，这种情况是很难达到的。还有就是hash表没有办法进行范围查询，这是不符合我们日常的数据规则的，再就是我们知道hash表的主要存储方式就是数组+链表，数组本身浪费空间。

为什么不用其他树？

二叉树
二叉排序树
AVL树
红黑树

上面的树都是二叉的，数据量多了以后层数太多，层数多会造成io的增加。因为上层节点里面含有下层节点的地址，所以取数据的时候需要先取出上层的节点，从上层节点拿下层节点的地址，然后取下层的节点。这样所有的二叉的树就可以pass掉了。

B树与B+树的选择

B树每个节点都存储key和data，所有节点组成这棵树，并且叶子节点指针为null。

B+树只有叶子节点存储data，叶子节点包含了这棵树的所有键值，叶子节点不存储指针。但是节点会有冗余。

B树和B+树都可以增加节点的分叉，减少树的层数，为什么就选择了B+树，肯定还是因为减少树的层数。B树会把索引和数据一起存储，这样一个节点内的数据数量就会减少。mysql在存储数据的时候，通常会以数据页的倍数为数据单位，数据页的大小与操作系统有关，mysql的数据单位大小为16k，也就是说mysql每次从数据库中读16k的数据，那这16k就作为一个节点。里面存什么东西就决定了查询时进行io的次数。如果选择B+树，我们假设一个索引+数据+指针为1kb，那么16kb/1kb=16条，一个节点最多存16个数据，三层一共存161616=4096条数据，那么如果我们用B+树存，忽略索引的冗余，假设索引+指针为10b 16kb/10b=1.6k ≈1600 160016001600/2 (只有最底层存数据，所以除2)，同样3层能存这么多条。

面试中的概念考察

回表

查询的数据列不在索引中

索引覆盖

不回表，（也是不推荐使用*的原因之一）

最左匹配

针对组合索引（联合主键）比如  id  name  age
（id）（name，age）
查询  select * from table where name=?  and age=?    y
select * from table where name=?     y
select * from table where age=?				n
select * from table where age=? and name=?   y ->会sql优化
注：当表中所有列都是索引列的时候，会反最左匹配原则

索引下推

select * from table where name=? and age=?

先获取到 name的结果 然后在service进行过滤

索引下推 直接在存储引擎中筛选 不需要在service进行过滤，减少了io

service层

连接器  管理连接验证权限

分析器  词法分析 语法分析->ast 抽象语法树antlr  calcite

优化器  优化sql语句的执行过程  
				cbo  基于成本的优化    Y
				rbo  基于规则的优化
执行器 与存储引擎进行交互
缓存    8.0之后去掉了
存储引擎
存储、组织数据，进行交互

key_length 怎么算？

整型

整型为4字节，可为null的话加上一个字节标识

varchar

根据不同的编码
vachar长度*编码长度+4标识varchar

聚簇索引和非聚簇索引

先说结论innodb使用聚簇索引，myisam使用非聚簇索引
innodb的存储文件有两个 表结构+索引和数据的组合
myisam的存储文件有三个 表结构+索引+数据

innodb中的索引B+树中数据为真实的行
myisam中的索引B+树中数据为数据地址
结果就是非聚簇需要多一次取数据

聚簇与B树B+树没有关系可以任意组合，当然上面说到的B树存储时拿聚簇索引举例，非聚簇多一次取数据带来的好处就是每个节点可以放更多的节点，这样同样3层可以存更多条数据，但是肯定比B+树差得远。

sql性能监控

show profile
performance_schma