欢迎您的访问
专注架构,Java,数据结构算法,Python技术分享

Mysql-innodb-B+索引

写在最前

这是读书笔记,Mysql,innodb系列一共3篇。

  • Mysql-innodb-B+索引(本篇)
  • Mysql-innodb-锁(预计20200523)
  • Mysql-innodb-事务预计20200530)

概述

下面是常见的建表语句:

CREATE TABLE `aid_***_detail` (
//省略所有字段
PRIMARY KEY (`id`),
KEY `range_idx` (`range_id`,`is_delete`,`range_detail_num`,`goods_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

 

其中的Key和PRIMARY就是 B+树索引,即常用的索引,大概率是B+树索引

注:mysql还有全文索引和hash索引。

Innodb的2种B+树索引

聚集索引

1、 以主键构建B+树,叶子节点存放一整行数据,聚集索引的叶子节点称为数据页
2、 每张表只有一个聚集索引
3、 逻辑连续,页通过双向链表连接,页中数据通过双向链表维护

主键排序查找和范围查找速度快。若高度为3,需要3次IO找到数据

辅助索引

1、 也称非聚集索引,不影响聚集索引,一张表上可以有多个辅助索引
2、 叶子节点,存储键值和书签。书签:聚集索引的键值
3、 辅助索引找主键索引,主键索引找完整记录

辅助索引B+树高度为3,聚集索引B+树高度为3,需要6次IO

Innodb创建索引的方式

聚集索引

新建表,将数据拷贝到新表,删除老表,将新表重命名

辅助索引(FIC机制)

表上加S锁,不用重建表,标记删除

允许读,阻塞写

注:关于锁的部分见下一篇blogMysql-innodb-锁

Cardinality 一个参数看索引好坏

索引中唯一项的估计值 ,Cardinality/n_rows_in_table 越接近1越好

n_rows_in_table 表中总记录数。

可以使用 show index from table 查看Cardinality的值。

Innodb对Cardinality的更新策略

  • 表中1/16 数据发生了变化
  • stat_modified_counter>2 000 000 000(20亿)
  • ANALYZE TABLE table_name 可以改变Cardinality,耗时慎用。

采集方式

Cardinality=(P1+P2+…+P8)*A/8

A索引中叶子节点的数量

P1、.P8, Pn表示当前页不同记录的个数

联合索引-使用技巧

(a,b,c)联合索引的B+树,简图如下:

68_3.png

从上图可以看出:

例如a,b,c形式的排序了

1,2,1 在1,2,2前。

但是a,c这种形式没有排序。

例如:2,1,4 ,2,2,3 都是 2,*,X的形式,X位没有排序。

下面进行测试:

创建测试表:

CREATE TABLE `aid_test` (
`id` varchar(32) NOT NULL COMMENT '主键',
`a` varchar(32) NOT NULL,
`b` varchar(32) NOT NULL,
`c` int(11) NOT NULL,
`is_delete` int(11) NOT NULL COMMENT '0未删除1已删除',
`create_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '创建时间',
`update_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '更新时间',
PRIMARY KEY (`id`),
KEY `range_idx` (`a`,`b`,`c`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ;

 

开始测试

若联合索引是(a,b,c)如下情况可以使用索引

select * from t where a=XX and b=xx and c=XXX

select * from t where a=XX and b=xx

select * from t where a=XX

通过执行计划,都可以看到,都走了索引。

68_6.png

测试排序

explain select * from t where a =XX order by b

explain select * from t where a =XX and b=XX order by c

可以看到,Extra项,只使用索引条件。

68_7.png

但是

explain select * from t where a =XX order by c

68_8.png

Extra项 有Using filesort!!!

如果待排序的内容不能由所使用的索引直接完成排序的话,那么mysql有可能就要进行文件排序

Using filesort。

经过测试证明了,聚合索引的排序方式。

尽量利用聚合索引的排序方式,优化查询。

补充-B+数据结构

68_9.png

为磁盘或其他直接存取辅助设备设计的一种平衡查找树

定义

1、数据存储在叶子节点上,所有数据按照键值排序,各个叶子节点指针相互连接

2、非叶子节点存储直到M-1个关键字以指示搜素的方向;关键字i代表子树i+1中最小的关键字。

3、树的根要么无子节点,要么其儿子数在2到M之间

4、除根外,所有非树叶节点的儿子数在[M/2]和M之间

5、所有的树叶都在相同的深度上并有[L/2]和L之间个数据项

6、M,L根据磁盘区块大小确定

B+数据结构操作

插入-裂项

叶子节点是否已经满了 索引节点是否已经满了 操作
记录直接插入到叶子节点
拆分叶子节点
叶子节点的中间值上升到索引节点
小于中间值的,放在新的左叶
大于等于中间值的,放在右叶
拆分叶子节点
叶子节点的中间值上升到索引节点
小于中间值的,放在新的左叶
大于等于中间值的,放在右叶
拆分索引节点
索引节点的中间值上升到上层索引节点
小于中间值的,放到左边索引节点
大于中间值的,放到右边新索引节点

删除合项

叶子节点小于填充因子 索引节点小于填充因子 操作
直接删除,
如果该节点,还在索引节点中,用该节点的右节点替代
合并叶子节点,同时更新索引节点
合并叶子节点,
合并索引节点和它的兄弟节点

InnoDB的裂项

总是从中间进行分裂,会造成空间浪费。

Innodb的方式为:

1、 随机插入时,从中间进行裂项
2、 同一方向插入5条,已定位的数据后还有3个数据。从已定位后的3个记录进行裂项

Page Header中决定的参数Page Last Insert,Page DIRECTION,Page_N_DIRECTION

赞(0) 打赏
版权归原创作者所有,任何形式转载请联系作者;码农code之路 » Mysql-innodb-B+索引

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏