MySQL/MariaDB的 B+ TREE索引

在我们CentOS 7+版本之后的自带镜像中的MariaDB使用的默认引擎是InnoDB引擎:

InnoDB引擎自带的特点:

1.InnoDB存储引擎将数据存储于"表空间"中;

2.支持事务

3.精细锁粒度支持;表级锁、页级锁、行级锁、间隙锁;

4.支持聚集索引,主键索引以及辅助索引,自适应的Hash索引;

简要介绍一下事务:

所谓事务:就是一组原子性的SQL查询或者是一个或多个SQL语句组成的独立的操作单元;

一个最简单易懂的事务例子:

A 借 B 100块钱,A 得到100,则相应的 B 就会减少100;这就是一个事务,因为不可能 A 借 B100之后,A增加了,而B却没减少;

对事务支持性能的测试标准;ACID标准;

A:原子性、整个事务中所有的操作是一个不可分割的整体,要么全部成功执行,要么在某操作执行失败后全部回滚值事务开启时的状态;

C:一致性、数据库的状态在执行事务之前和提交事务之后必须要保持数据状态一致性;

I:隔离性、独立性、并发控制的管理机制;

D:持久性、事务一旦提交,其所作出的所有修改将永久保存并持久有效;

B+ TREE索引:

顺序存储,所有的索引数据都存放在叶节点上,并且每个叶节点都有顺序访问指针,以此指针指向相邻的叶子节点。这样做可以提高区间数据的查询效率;

适用的场景:

全键值匹配:精确匹配某个值;

select ... where Name='guo jing';

左前缀匹配:只精确到数据起始位置的一部分;

select ... where Name like 'guo%';

区间数据的连续数值匹配:通常用于BETWEEN ... AND ...环境中;

select ... where Age between 30 and 50;

区间数据的离散值匹配:通常用于IN列表环境或OR列表环境:也是精确值匹配;

select ... where StuID in (1,4,7,10);

精确匹配左列,范围匹配右侧其他列:

select ... wherer StuID > 10 and Name like "a%";

对于覆盖索引的查询请求:

不适用的场景:

如果查询条件不是精确从最左侧列开始的,索引无效;

如:对StuID字段做了索引,select ... where Name like 'a%' and 'StuID' > 10;

如果索引了多列,若跳过索引中的某列,则索引无效;

如:对StuID,Name,Age做索引,select ... where StuID>0 and Age>20;

如果索引了多列,且在查询语句中对某个列做范围匹配,则其右侧列不能在使用索引优化查询;

如:对StuID,Name,Age做索引,select ... where StuID>0 and Name like 'a%';

HASH索引:基于HASH表实现的索引;非常适用于值的精确匹配的查询请求;

注意:

1.在InnoDB存储引擎中,创建索引时,只能显式使用"B+ TREE"索引;

2.索引中的数据来源于数据表,但数据结构与原数据有很大差异;

查看数据库的索引:用EXPLAIN语句;

MariaDB [hellodb]> explain select  * from students where StuID<10\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: students
         type: range
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 9
        Extra: Using where
1 row in set (0.00 sec)

id:当前的SELECT查询语句中,各个SELECT语句的编号;

select_type:查询类型:

简单查询:SIMPLE

复杂查询:

简单的子查询(用于where子句中的子查询):SUBQUERY

用于FROM语句中的子查询:DERIVED

联合查询中的第一个查询:PRIMARY

联合查询中其他的查询:UNION

联合查询时生成的临时表查询:UNION RESULT

table:当前的查询语句所针对的表;

type:关联类型,或称为访问类型;也可以理解为MySQL是如何查询表中的行;

ALL:全表扫描,MySQL将遍历权标以找到可以匹配的行;

index:全部扫描,与ALL所不同的是index类型只是遍历索引树;

range:索引范围扫描,对索引的扫描从某一个点开始,返回匹配值域的行;

通常可以基于指定的索引,使用IN列表、BETWEEN ... AND ...或带有哦"=","<", ">"的查询;

ref:使用非唯一索引扫描或者使用唯一索引的左前缀扫描,返回匹配某个单独的行;

eq_ref:类似ref,区别就是使用唯一索引,对于每一个索引键值,表中都只有一条记录匹配;无论是单表查询还是多表查询,都是要主键或唯一键索引作为关联条件;

const,system:当MYSQL对查询部分进行优化,并转换为一个常量,使用const类型;

system类型是一个const类型特例,当要查询的表中只有一行时,使用system类型;

NULL:MySQL在优化过程中分解查询语句,执行时不用访问表或索引;

possible_keys:为了执行查询语句,MySQL可能使用哪个索引在表中查找到记录;

如果查询涉及到的字段上存在索引,则该索引会被列出,但不一定会被查询使用;

keys:显示MySQL在查询过程中实际使用到的索引;如果查询过程没有用到任何索引,则此处显示为"NULL";

key_len:表示索引中可以被引用的最大的字节数;可以通过该列计算查询中使用的索引的长度:

注意:key_len显示的值通常为索引字段的最大可能长度,并不是实际的使用长度;因此key_len是根据定义时指定的字段长度计算得到的,而并不是在表中通过检索数据得到的;

ref:在利用key字段所显示的索引完成查询操作时所引用的列或常量值;如果都没有,则显示为"NULL";

rows:表示MySQL根据表统计信息及索引选用的情况,估算的本次检索所需要查找索引记录的过程中需要读取的表的行数;

Extra:额外信息,或称为扩展信息;

Using where:表示MySQL服务器将在存储检索后在次进行条件过滤;许多的where条件里涉及到索引中的列并且当MySQL读取该索引时,就可以被存储引擎检验;

Using index:使用了覆盖索引进行检索;

Using tempory:在查询过程中使用了临时表存放查询结果集;常见于排序或分组查询;

Using filesort:MySQL中无法利用索引完成排序;

Using join buffer:强调了在获取连接条件时没有使用都索引,并且需要连接缓冲区来存储中间结果;如果出现了该值,需要根据查询的具体情况适当的添加索引以提示查询性能;

Impossible where:如果该值出现,则意味着在查询时没有发现符合条件的行;

Select tables optimized away:该值意味着仅通过使用索引来进行查询,但是优化器可能从聚合函数的结果中给出一个可行的优化方案;

Using sort-union(...)

Using union(...)

Using intersect(...)

上述情况多出现于在实现查询的过程中,决定使用不止一个索引时;

filtered:从可选的行中再次过滤之后选择出最终的查询结果的比值;可以理解为从多少行中过滤选择出多少行的比值;

原文地址:http://blog.51cto.com/liujingyu/2151224

时间: 2024-10-10 06:04:27

MySQL/MariaDB的 B+ TREE索引的相关文章

Mysql B-Tree和B+Tree索引

Mysql B-Tree和B+树索引 Mysql加快数据查找使用B-Tree数据结构存储索引数据,InnoDB存储引擎实际使用B+Tree.下面首先介绍下B-Tree和B+Tree的区别: 一.B树和B+树索引(手绘图简要说明) 1.B-Tree索引: 2.B+Tree索引: 3.B-Tree 和B+Tree索引查找原理: 非叶子节点存储索引关键字,叶子节点指针指向的是被索引的数据.节点槽中存放了指向子节点的指针(可以理解为两个关键字之间),存储引擎根据这些指针向下层查找.通过比较节点页的值和要

MySQL/MariaDB基础

数据库管理系统很早就有了,在最开始时,数据库管理的结构是层次化的,即层次模型,它是一个树形结构,可以通过有限次的查找来定位需要的数据,然而,这种查找还是需要遍历才能实现,所以这种模型应用时间不长久:之后有了网状模型,也就是多个树的集合:层次模型和网状模型都称为非关系型数据库.之后由Edgar Frank Codd提出了一个关系型数据库的模型,从此之后就有了关系模型,其中Oracle公司就是以此为原型开发了Oracle数据库:到现在又提出了反关系模型--No-SQL,它是非关系型的数据库,例如:键

关于数据库管理系统DBMS--关系型数据库(MySQL/MariaDB)

数据库管理系统--DBMS:用来管理数据库 数据库的结构(3种):层次,网状,关系型(用的最多): DBMS的三层模型: 视图层:面向最终用户: 逻辑层:面向程序员或DBA: 物理层:面向系统管理员: 关系型数据库管理系统--RDBMS: 主要的组成部分是表:表是由行(实例,实体,记录)和列(字段,域)组成: 关系型数据库管理系统的实现: 商业方案:Oracle,Sybase{为微软提供了思路出现SQL-server},Infomix{IBM收购},DB2{IBM} 开源方案:PostgreSQ

MySQL/MariaDB基础(2)

MariaDB查询缓存 缓存中的数据是开源形式的,以键值对(k/v)的形式存在 key:查询语句的hash值: value:查询语句的查询结果: 缓存中的数据主要是通过整个查询语句的hash值的比较,完全相同则命中:这样通过缓存响应客户端请求,可以提高检索效率:当然,也不是所有的查询数据都可以缓存,那么哪些数据不能够缓存呢? 1.要查询的数据库中可能包含敏感信息:如MySQL数据库中的各系统表: 2.在查询语句中包含有用户自定义的函数(UDF) 3.存储函数: 4.用户自定义变量: 5.对于临时

Mysql优化之创建高性能索引(一)

1.索引基础 索引对于良好的性能非常关键.尤其是当表中的数据量越来越大时,索引对性能的影响愈发重要.但是不恰当的索引随着数据量的增加,也会使整个数据库的性能下降. 举个例子: select a from b where id = 5; 如果在id上建立索引,则Mysql会使用该索引找到id为5的行,也就是说,Mysql现在索引按值进行查找,然后返回所有包含该值的数据行.索引也可以包含一列或者多列,列的顺序也十分重要,因为Mysql只能高效地使用索引的最左前缀列. 索引优化应该是查询性能优化最有效

MySQL/MariaDB基础性知识及DDL操作详解

前言 MySQL/MariaDB是一个开放源码的小型关联式数据库管理系统,由于其体积小.速度快.总体拥有成本低,尤其是开放源码这一特点,许多中小型网站为了降低网站总体拥有成本而选择了MySQL/MariaDB作为网站数据库. 基础架构 MySQL核心组件 连接池:认证.线程重用.连接数限制.内存检查.缓存 SQL接口:DDL, DML, 关系型数据库的基本抽象 parser: 查询转换.对象权限检查 优化器:访问路径,性能相关的统计数据 caches和buffers:与存储引擎自身相关的I/O性

MySQL/MariaDB数据库备份与恢复

前言 数据库一般存放着企业最为重要的数据,它关系到企业业务能否正常运转,数据库服务器总会遇到一些不可抗拒因素,导致数据丢失或损坏,而数据库备份可以帮助我们避免由于各种原因造成的数据丢失或着数据库的其他问题.本文将讲解MySQL/MariaDB数据库的几种备份方法. 基础知识 备份类型 完全备份:备份整个数据库 部分备份:仅备份其中的一张表或多张表 增量备份:仅备份从上次完全备份或增量备份之后变化的数据部分 差异备份:备份上次备份后变化的数据部分,和增量备份区别在于差异备份只可以相对完全备份做备份

linux架构学习第二十八天之Mysql/MariaDB数据库入门

内容: 1.数据库简介以及mysql/mariadb背景介绍 2.数据库的一些名词 3.mysql的服务结构 4.mysql客户端的使用 5.数据类型 6.SQL语句介绍 7.mysql的事务机制 一.数据库简介以及mysql/mariadb背景介绍 数据可以存放在多种位置,如普通文件.专门的数据库中,而两者有什么区别,而为什么选择数据库存储?我们知道,假如数据存在普通文件中,当我们要查找其中的一个数据时,要把整个文件加载到内存中,再进行检索,这样速度慢不说,一旦文件较大,直接把内存撑爆了,而数

淘宝内部分享:MySQL &amp; MariaDB性能优化

淘宝内部分享:MySQL & MariaDB性能优化 发表于2015-01-20 16:26| 17496次阅读| 来源mysql.taobao.org| 21 条评论| 作者淘宝数据库团队 MySQL性能优化淘宝数据库 摘要:MySQL是目前使用最多的开源数据库,但是MySQL数据库的默认设置性能非常的差,必须进行不断的优化,而优化是一个复杂的任务,本文描述淘宝数据库团队针对MySQL相关的数据库优化方案. 编者按:MySQL是目前使用最多的开源数据库,但是MySQL数据库的默认设置性能非常的