浅析MysQL B-Tree 索引

B-Tree 索引

不同的存储引擎也可能使用不同的存储结构,i如,NDB集群存储引擎内部实现使用了T-Tree结构存储这种索引,即使其名字是BTREE;InnoDB使用的是B+Tree。

B-Tree通常一位这所有的值都是按顺序存储的,并且每一个叶子页道根的距离相同。下图大致反应了InnoDB索引是如何工作的。

为什么mysql索引要使用B+树,而不是B树,红黑树

看完上面的文章就可以理解为何B-Tree索引能够快速访问数据了。因为存储引擎不再需要进行全表扫描获取需要的数据,叶子节点包含了所有元素信息,每一个叶子节点指针都指向下一个节点,所以很适合查找范围数据。

索引对多个值进行排列的依据是CREATE TABLE 语句中定义索引时的顺序。

那么,索引排序的规则就是按照 last_name ,first_name ,dob 的顺序来的。

可以使用 B-Tree 索引的查询类型
B-Tree索引适用于全键值、键值范围或键前缀查找。
键前缀查找只是用于根据最左前缀查找。

举个粒子:

CREATE TABLE People (
  last_name VARCHAR ( 50 ) NOT NULL,
  first_name VARCHAR ( 50 ) NOT NULL,
  dob date NOT NULL,
  gender enum ( 'm', 'f' ) NOT NULL,
KEY ( last_name, first_name, dob )
);

这个表的索引如下:

type结果

type结果值从好到坏依次是:

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

一般来说,得保证查询至少达到range级别,最好能达到ref,否则就可能会出现性能问题。

possible_keys:sql所用到的索引

key:显示MySQL实际决定使用的键(索引)。如果没有选择索引,键是NULL

(1)全值匹配
全值匹配指的是和索引中的所有列进行匹配。

例如上面的People表的索引(last_name,first_name,dob)可以用于查找last_name='Cuba Allen',first_name='Chuang',dob='1996-01-01'的人。这就是使用了索引中的所有列进行匹配,即全值匹配。

mysql> EXPLAIN select * from People where last_name = 'aaa' and first_name = 'bbb' and dob='2020-11-20' \G;
*************************** 1. row ***************************
     id: 1
 select_type: SIMPLE
    table: People
 partitions: NULL
    type: ref
possible_keys: last_name
     key: last_name  <-----可以看到这个key就是我们定义的索引
   key_len: 307
     ref: const,const,const
    rows: 1
  filtered: 100.00
    Extra: NULL
1 row in set, 1 warning (0.00 sec)

ERROR:
No query specified

(2)匹配最左前缀
可以只使用索引的第一个列进行匹配。

例如可以用于查找last_name='aaa'的人,即用于查找姓为Zeng的人,这里只使用了索引的最左列进行匹配,即匹配最左前缀。

mysql> EXPLAIN select * from People where last_name = 'aaa' \G;
*************************** 1. row ***************************
     id: 1
 select_type: SIMPLE
    table: People
 partitions: NULL
    type: ref
possible_keys: last_name
     key: last_name  <----使用了索引
   key_len: 152
     ref: const
    rows: 3
  filtered: 100.00
    Extra: NULL
1 row in set, 1 warning (0.00 sec)

ERROR:
No query specified

(3)匹配列前缀
可以只匹配某一列的值的开头部分。

例如可以用于查找last_name LIKE ‘a%'的人,即用于查找所有以Z开头的姓的人,这里只使用了索引最左列的前缀进行匹配,即匹配列前缀。

mysql> EXPLAIN select * from People where last_name = 'a%' \G;
*************************** 1. row ***************************
     id: 1
 select_type: SIMPLE
    table: People
 partitions: NULL
    type: ref
possible_keys: last_name
     key: last_name   <---使用了索引
   key_len: 152
     ref: const
    rows: 1
  filtered: 100.00
    Extra: NULL
1 row in set, 1 warning (0.00 sec)

ERROR:
No query specified

(4)匹配范围值
可以只适用索引的第一列查找符合某个范围内的数据。

例如可以用于查找last_name BETWEEN ‘aaa' AND ‘aaabbbccc'的人,即用于查找姓在aaa和aaabbbccc之间的人,这里只使用了索引最左列的前缀进行范围匹配,即匹配范围值。

mysql> EXPLAIN select * from People where last_name BETWEEN 'aaa' and 'aaabbbccc'\G;
*************************** 1. row ***************************
     id: 1
 select_type: SIMPLE
    table: People
 partitions: NULL
    type: range
possible_keys: last_name
     key: last_name  <---使用了索引
   key_len: 152
     ref: NULL
    rows: 3
  filtered: 100.00
    Extra: Using index condition
1 row in set, 1 warning (0.00 sec)

ERROR:
No query specified

(5)精确匹配某一列并范围匹配另外一列
可以使第一列全匹配,第二列范围匹配。

例如可以用于查找last_name='aaa' AND first_name LIKE 'b%'的人,即用于查找姓是Zeng,名字以C开头的人,这里使用了索引的最左列精确匹配,第二列进行范围匹配。

mysql> EXPLAIN select * from People where last_name = 'aaa' and first_name like 'b%'\G;
*************************** 1. row ***************************
     id: 1
 select_type: SIMPLE
    table: People
 partitions: NULL
    type: range
possible_keys: last_name
     key: last_name  <---使用了索引
   key_len: 304
     ref: NULL
    rows: 1
  filtered: 100.00
    Extra: Using index condition
1 row in set, 1 warning (0.00 sec)

ERROR:
No query specified

(6)只访问索引的查询
查询只需访问索引,而无须访问数据行。

例如select last_name, first_name where last_name='aaa'; 这里只查询索引所包含的last_name和first_name列,则无须读取数据行。

mysql> explain select last_name,first_name,dob from People where last_name = 'aaa'
*************************** 1. row ***************************
      id: 1
 select_type: SIMPLE
    table: People
  partitions: NULL
     type: ref
possible_keys: last_name
     key: last_name
   key_len: 152
     ref: const
     rows: 1
   filtered: 100.00
    Extra: Using index
1 row in set, 1 warning (0.00 sec)

ERROR:
No query specified

B-Tree 的限制

(1)只能按照索引的最左列开始查找。
例如People表中的索引无法用于查找first_name为'bbb'的人,也无法查找某个特定生日的人,因为这两个列都不是最左数据列。

(2)只能按照索引最左列的最左前缀进行匹配。
例如People表中的索引无法查找last_name LIKE ‘%b'的人,虽然last_name就是此索引的最左列,但MySQL索引无法查找以‘b'结尾的last_name的记录。

(3)只能按照索引定义的顺序从左到右进行匹配,不能跳过索引中的列。
例如People表中的索引无法用于查找last_name='a' AND bod='1996-01-01'的人,因为MySQL无法跳过索引中的某一列而使用索引中最左列和排在末尾的列进行组合。如果不指定索引中中间的列,则MySQL只能使用索引的最左列,即第一列。

(4)如果查询中有某个列的范围查询,则其右边所有列都无法使用索引优化查找。
例如有这样一个查询:where last_name='a' AND first_name LIKE 'b%' AND dob='1996-01-01'; 这个查询只能使用索引的前两列,因为这里LIKE是一个范围条件,则first_name后面的索引列都将失效。(优化点:尽量不要在索引列中使用LIKE等范围条件,改用多个等于条件来替代,保证后面的索引列能生效。)

以上就是浅析MysQL B-Tree 索引的详细内容,更多关于MysQL B-Tree 索引的资料请关注我们其它相关文章!

(0)

相关推荐

  • MySQL Hash索引和B-Tree索引的区别

    MySQL Hash索引结构的特殊性,其检索效率非常高,索引的检索可以一次定位,不像B-Tree 索引需要从根节点到枝节点,最后才能访问到页节点这样多次的IO访问,所以 Hash 索引的查询效率要远高于 B-Tree 索引. 可 能很多人又有疑问了,既然 Hash 索引的效率要比 B-Tree 高很多,为什么大家不都用 Hash 索引而还要使用 B-Tree 索引呢?任何事物都是有两面性的,Hash 索引也一样,虽然 Hash 索引效率高,但是 Hash 索引本身由于其特殊性也带来了很多限制和弊

  • MySQL优化中B树索引知识点总结

    为什么要进行SQL优化呢?很显然,当我们去写sql语句时: 1会发现性能低 2.执行时间太长, 3.或等待时间太长 4.sql语句欠佳,以及我们索引失效 5.服务器参数设置不合理 SQL语句执行过程分析 1.编写过程: 编写过程就是我们平常写sql语句的过程,也可以理解为编写顺序,以下就是我们编写顺序: select from join on where 条件 group by 分组 having过滤组 order by排序 limit限制查询个数 我们虽然是这样去写的,但是它mysql的引擎去

  • 为什么MySQL数据库索引选择使用B+树?

    在进一步分析为什么MySQL数据库索引选择使用B+树之前,我相信很多小伙伴对数据结构中的树还是有些许模糊的,因此我们由浅入深一步步探讨树的演进过程,在一步步引出B树以及为什么MySQL数据库索引选择使用B+树! 学过数据结构的一般对最基础的树都有所认识,因此我们就从与我们主题更为相近的二叉查找树开始. 一.二叉查找树 (1)二叉树简介: 二叉查找树也称为有序二叉查找树,满足二叉查找树的一般性质,是指一棵空树具有如下性质: 1.任意节点左子树不为空,则左子树的值均小于根节点的值: 2.任意节点右子

  • 获取 MySQL innodb B+tree 的高度的方法

    前言 MySQL 的 innodb 引擎之所以使用 B+tree 来存储索引,就是想尽量减少数据查询时磁盘 IO 次数.树的高度直接影响了查询的性能.一般树的高度在 3~4 层较为适宜.数据库分表的目的也是为了控制树的高度.那么如何获取树的高度呢?下面使用一个示例来说明如何获取树的高度. 示例数据准备 建表语句如下: CREATE TABLE `user` (   `id` int(11) NOT NULL AUTO_INCREMENT,   `name` varchar(100) CHARAC

  • Mysql中的Btree与Hash索引比较

    mysql最常用的索引结构是btree(O(log(n))),但是总有一些情况下我们为了更好的性能希望能使用别的类型的索引.hash就是其中一种选择,例如我们在通过用户名检索用户id的时候,他们总是一对一的关系,用到的操作符只是=而已,假如使用hash作为索引数据结构的话,时间复杂度可以降到O(1).不幸的是,目前的mysql版本(5.6)中,hash只支持MEMORY和NDB两种引擎,而我们最常用的INNODB和MYISAM都不支持hash类型的索引. 不管怎样,还是要了解一下这两种索引的区别

  • 浅谈MySQL的B树索引与索引优化小结

    MySQL的MyISAM.InnoDB引擎默认均使用B+树索引(查询时都显示为"BTREE"),本文讨论两个问题: 为什么MySQL等主流数据库选择B+树的索引结构? 如何基于索引结构,理解常见的MySQL索引优化思路? 为什么索引无法全部装入内存 索引结构的选择基于这样一个性质:大数据量时,索引无法全部装入内存. 为什么索引无法全部装入内存?假设使用树结构组织索引,简单估算一下: 假设单个索引节点12B,1000w个数据行,unique索引,则叶子节点共占约100MB,整棵树最多20

  • MySQL btree索引与hash索引区别

    在MySQL中,大多数索引(如 PRIMARY KEY,UNIQUE,INDEX和FULLTEXT)都是在BTREE中存储,但使用memory引擎可以选择BTREE索引或者HASH索引,两种不同类型的索引各自有其不同的使用范围. B树索引具有范围查找和前缀查找的能力,对于有N节点的B树,检索一条记录的复杂度为O(LogN).相当于二分查找. 哈希索引只能做等于查找,但是无论多大的Hash表,查找复杂度都是O(1). 显然,如果值的差异性大,并且以等值查找(=. <.>.in)为主,Hash索引

  • 浅析MysQL B-Tree 索引

    B-Tree 索引 不同的存储引擎也可能使用不同的存储结构,i如,NDB集群存储引擎内部实现使用了T-Tree结构存储这种索引,即使其名字是BTREE:InnoDB使用的是B+Tree. B-Tree通常一位这所有的值都是按顺序存储的,并且每一个叶子页道根的距离相同.下图大致反应了InnoDB索引是如何工作的. 为什么mysql索引要使用B+树,而不是B树,红黑树 看完上面的文章就可以理解为何B-Tree索引能够快速访问数据了.因为存储引擎不再需要进行全表扫描获取需要的数据,叶子节点包含了所有元

  • 浅析MySQL索引结构采用B+树的问题

    目录 1.B树和B+树 2.原因分析 3.总结 一位6年经验的小伙伴去字节面试的时候被问到这样一个问题,为什么MySQL索引结构要采用B+树?这位小伙伴从来就没有思考过这个问题.只因为现在都这么卷,后面还特意查了很多资料,他也希望听听我的见解. 另外,我花了1个多星期把往期的面试题解析配套文档准备好了,一共有10万字,想获取的小伙伴可以在我的煮叶简介中找到. 1.B树和B+树 一般来说,数据库的存储引擎都是采用B树或者B+树来实现索引的存储.首先来看B树,如图所示. B树是一种多路平衡树,用这种

  • MySQL B-tree与B+tree索引数据结构剖析

    目录 一.产生的背景 1.1 进化要求 二.B-tree 2.1 B-tree特性 三.B+tree 3.1 B+tree特性 四.结论 一.产生的背景 二叉查找树的查找时间复杂度是O(logN),整体的查询效率已经足够高了,那么为什么还会有B树和B+树的进化演进呢? 主要的原因是:二叉树可能会退化成一个线性树,造成磁盘IO次数增高的问题,当有大量的数据存储的时候,二叉查找树查询不能将所有的数据加载到内存中,只能逐一加载磁盘页,每个磁盘对应树的节点,造成大量的磁盘IO操作(最坏的情况IO次数为树

  • 深入浅析Mysql联合索引最左匹配原则

    前言 之前在网上看到过很多关于mysql联合索引最左前缀匹配的文章,自以为就了解了其原理,最近面试时和面试官交流,发现遗漏了些东西,这里自己整理一下这方面的内容. 最左前缀匹配原则 在mysql建立联合索引时会遵循最左前缀匹配的原则,即最左优先,在检索数据时从联合索引的最左边开始匹配,示例: 对列col1.列col2和列col3建一个联合索引 KEY test_col1_col2_col3 on test(col1,col2,col3); 联合索引 test_col1_col2_col3 实际建

  • 浅析MySQL的基数统计

    一.基数是啥? Cardinality指的就是MySQL表中某一列的不同值的数量. 如果这一类是唯一索引,那基数 = 行数. 如果这一列是sex,枚举类型只有男女,那它是基数就是2 Cardinality越高,列就越有成为索引的价值.MySQL执行计划也会基于Cardinality选择索引. 通过下面的方式可以看到表中各列的基数. 比如这个经典的例子: 有一列为sex,那对于sex列中存储的值来说 非男即女,它的基数最大就是2. 那也就完全没有必要为sex建立索引.因为,为了提升你基于sex的查

  • 浅谈MySQL和Lucene索引的对比分析

    MySQL和Lucene都可以对数据构建索引并通过索引查询数据,一个是关系型数据库,一个是构建搜索引擎(Solr.ElasticSearch)的核心类库.两者的索引(index)有什么区别呢?以前写过一篇<Solr与MySQL查询性能对比>,只是简单的对比了下查询性能,对于内部原理却没有解释,本文简单分析下两者的索引区别. MySQL索引实现 在MySQL中,索引属于存储引擎级别的概念,不同存储引擎对索引的实现方式是不同的,本文主要讨论MyISAM和InnoDB两个存储引擎的索引实现方式. M

  • 详解mysql权限和索引

    mysql权限和索引 mysql的最高用户是root, 我们可以在数据库中创建用户,语句为CREATE USER 用户名 IDENTIFIED BY '密码',也可以执行CREATE USER 用户名 语句来创建用户,不过此用户没有密码,可以将用户登录后进行密码设置:删除用户语句为DROP USER 用户:更改用户名的语句为RENAME USER 老用户名 to 新用户名: 修改密码语句为set password=password('密码'): 高级用户修改别的用户密码的语句为SET PASSW

  • 深入浅析MySQL从删库到跑路_高级(一)——数据完整性

    一.数据完整性简介 1.数据完整性简介 数据冗余是指数据库中存在一些重复的数据,数据完整性是指数据库中的数据能够正确反应实际情况. 数据完整性是指数据的可靠性和准确性,数据完整性类型有四种: A.实体完整性:实体的完整性强制表的标识符列或主键的完整性(通过唯一约束,主键约束或标识列属性). B.域完整性:限制类型(数据类型),格式(通过检查约束和规则),可能值范围(通过外键约束,检查约束,默认值定义,非空约束和规则). C.引用完整性:在删除和输入记录时,引用完整性保持表之间已定义的关系.引用完

  • 浅析MySQL 锁和事务

    MySQL本身也是在文件系统的基础上发展而来,因为锁的存在使之有所不同. MySQL作为一种数据库软件,难免会存在对其共享资源的并发访问,为了协调和管理不同资源的并发访问,也就产生了锁机制,因为锁机制的存在为数据库提供了数据的完整性和一致性. 从锁的级别来分锁可分为:行级锁.表级锁.页级锁. 从锁的类型来分锁可分为:共享锁.排它锁(独占锁). 为了协调行锁.表锁产生了:意向锁(表级锁). 共享锁,允许事务去读取数据. 排它锁,允许事务去修改或删除数据. 意向锁,获取行级锁的时候,自动添加的表级锁

  • MySQL创建高性能索引的全步骤

    一.索引基础 1. 索引的类型 1.1 B-Tree 索引 大多数MySQL存储引擎默认使用的是B+树的索引,不同的存储引擎用不同的方式使用B+树索引,MyISAM使用前缀压缩技术使得索引更小,但是InnoDB则按照元数据格式进行存储:MyISAM索引通过数据的物理位置引用被索引的行,而InnoDB则根据主键引用被索引的行. B树 和 B+ 树 B树: B+树: 区别: B树的关键字和记录是放在一起的,叶子节点可以看作外部节点,不包含任何信息:B+树的非叶子节点中只有关键字和指向下一个节点的索引

随机推荐