Mysql之B树索引

聚集索引:
简单概念:一个表中根据主键创建的一棵B+树,索引的叶子节点存放了表中所有的记录,存储记录在物理位置上是连续的,一个叶子节点存放一条对应的记录(PS:是根据主键创建的B+树,叶子节点存数据记录) 。
举个例子(以汉语字典为例):
汉语字典的正文本身就是一个聚集索引,比如我们要查“安”字,由于汉语词典的拼音排序是从“a”开始到“z”结尾的,则“安”字自然而然就排在字典前部,若翻遍了所有以“a”开头的部分仍找不到该字,则说明“安”不在字典中;同理,若想查“张”字,我们会将字典翻到最后一部分,因为拼音是“zhang”。而在我们的这些查找中,我们仅仅依靠正文就可以进行相应的查找;也就是说,字典的正文部分本身就是一个目录,我们不需要再通过其他目录的查找来找到我们需要的内容。正文内容本身就是按照一定规则排列的目录便称为“聚集索引”。每个表只能有一个聚集索引,因为目录只能按照一种方法进行排列,且每个表的主键是唯一的 。
非聚集索引:
简单概念:非聚集索引是根据索引字段创建的一棵B+树,索引的叶子节点仅存放索引键值以及该键值指向的主键,存储记录在逻辑上是连续的(PS:根据索引字段创建的B+树,叶子节点只存放索引键值与记录的主键)
举个例子(还是以汉语字典为例):
当我们遇到不认识的字且不知道它的发音,这时候,我们就不能按照前面的方法找到要查的字,而是需要根据“偏旁部首”查找要找的字,然后根据这个字后的页码直接翻到某页来找到要找的字,但我们结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法,比如我们查“张”字,在查部首之后的检字表中“张”的页码是672页,检字表中“张”的上面是“弛”字,但页面却是63页,“张”的下面是“弩”字,页面是390页,很显然,这些字在正文中并不是真正的分别处于“张”字的上下方,现在看到的连续的“弛,张,弩”三字的顺序实际上就是它们在非聚集索引中的排序,是字典正文中的字在非聚集索引中的映射,我们可以通过这种方式来找到所需要的字,但这包含2个过程,先找到目录中的结果,再根据找到的结果来翻到我们所需要的页面,这种目录纯粹是目录,正文纯粹是正文的排序方式就是“非聚集索引” 。
聚集索引与非聚集索引的主要区别:
a.存储特点的区别:
聚集索引按索引顺序来存储,索引项顺序与表中记录的物理顺序一致,叶子节点即存储了真实数据行,不再有另外的单独数据页,一张表上最多只有一个聚集索引;
非聚集索引表的存储顺序与索引顺序无关,仅仅索引项的逻辑上是连续的,叶子节点存储了索引字段值以及指向数据页数据行的逻辑指针,其行数量与数据表行数据量一致。 

b.更新表数据的区别:
插入数据:无聚集索引的表,表中数据行没特定顺序,新行皆被添加到表的末尾;有聚集索引的表,先根据索引找到对应的数据页,挪动已有记录为新数据腾出空间后插入,若数据页已满,则拆分数据页,调整索引指针(若表中有非聚集索引,则更新索引指向新的数据页);
删除数据:无聚集索引的表,直接删除(留下内存空洞);有聚集索引的表,删除行将导致其下的数据行向上移动以填补空白,若删除的行为数据页最后一行,则回收该数据页,相应索引页中记录也被删除。 
InnoDB的B+树索引:
a.InnoDB是索引组织表的,即数据文件本身就是按照B+树方式存放数据的;
b.InnoDB引擎中可以有聚集索引与非聚集索引,这2种索引每个页大小都为16k,且不能更改;
c.由于非聚集索引不包含行记录所有数据,因此每页可以存放比聚集索引更多的键值,高度一般都小于聚集索引;
d.若在InnoDB表建立时没显式指定主键,则InnoDB会自动创建一个6字节的列作为主键;
e.InnoDB中,主键的值会附加在每个非主键索引(非聚集索引)对应记录后面,无需重复添加到覆盖索引列中,这也是为什么我们常说InnoDB主键长度越小越好;
f.若非聚集索引是包含主键的联合索引,也不需要一个额外的列存放主键值,它会通过联合索引中的主键进行查找。
小图一张,展示下InnoDB中聚集索引与非聚集索引的关系 。

MyISAM 的B+树索引:
a.MyISAM是堆组织表,没有聚集索引的概念;
b.MyISAM表所有的行数据都存放在MYD文件中,B+树索引都存放在MYI文件中,且都是非聚集索引;
c.主键索引与其他索引不同之处在于必须是唯一的,且不可为null,索引页大小为1k,且不可调整;
d.由于没有聚集索引,故其索引叶节点存放的键值不是主键值,而是对应记录在MYD文件中的物理位置;
这也是为什么MyISAM表记录删除之后数据文件大小没什么变化,留下内存碎片,造成“空洞”的现象(可用 “OPTIMIZE TABLE 表名” 进行定期清理,会锁表)。
小图一张,展示下MyISAM中MYD与MYI的关系 

原文地址:https://www.cnblogs.com/cbxBlog/p/9192970.html

时间: 2024-08-30 08:57:40

Mysql之B树索引的相关文章

MySQL的B树索引与索引优化

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

浅谈MySQL的B树索引与索引优化

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

搞懂Mysql InnoDB B+树索引

一.InnoDB索引 InnoDB支持以下几种索引: B+树索引 全文索引 哈希索引 本文将着重介绍B+树索引.其他两个全文索引和哈希索引只是做简单介绍一笔带过. 哈希索引是自适应的,也就是说这个不能人为干预在一张表生成哈希索引,InnoDB会根据这张表的使用情况来自动生成. 全文索引是将存在数据库的整本书的任意内容信息查找出来的技术,InnoDB从1.2.x版本支持.每张表只能有一个全文检索的索引. B+树索引是传统意义上的索引,B+树索引并不能根据键值找到具体的行数据,B+树索引只能找到行数

Mysql之B+树索引实战

索引代价 空间上的代价 一个索引都对应一棵B+树,树中每一个节点都是一个数据页,一个页默认会占用16KB的存储空间,所以一个索引也是会占用磁盘空间的. 时间上的代价 索引是对数据的排序,那么当对表中的数据进行增.删.改操作时,都需要去维护修改内容涉及到的B+树索引.所以在进行增.删.改操作时可能需要额外的时间进行一些记录移动,页面分裂.页面回收等操作来维护好排序. B+树索引实战 以下示例是如下数据: CREATE TABLE t1( a int PRIMARY KEY, b INT, c IN

mysql 学习 - B+树索引

我们已经知道在单一数据页中查找数据时, 如果查找条件是主键的话, 可以使用二分法定位槽, 然后顺序遍历槽中的数据查找指定数据. 但是我们并不知道如何在数以万计的页中定位数据在哪个页中, 在没有索引的情况下,不论是根据主键列或者其他列的值进行查找,由于我们并不能快速的定位到记录所在的页,所以只能从第一个页沿着双向链表一直往下找,在每一个页中根据我们刚刚唠叨过的查找方式去查找指定的记录. 简单索引介绍 为了能够快速定位数据在哪个页中, 索引规定, 下一个数据页中用户记录的主键值必须大于上一个页中用户

MySQL中B+树索引的使用

1)         不同应用中B+树索引的使用 对于OLTP应用,由于数据量获取可能是其中一小部分,建立B+树索引是有异议时的 对OLAP应用,情况比较复杂,因为索引的添加应该是宏观的而不是微观的. 2)         联合索引 对表上多个列进行索引.联合索引的创建方法与多个索引创建的方法一样.不同之处在于有多个索引页 CREATE TABLE t( a INT, b INT, PRIMARY KEY(a), KEY idx_a_b(a,b) )ENGINE=INNODB 从本质上来说,联合

MySQL之B+树索引(转自掘金小册 MySQL是怎样运行的,版权归作者所有!)

每个索引都对应一棵B+树,B+树分为好多层,最下边一层是叶子节点,其余的是内节点.所有用户记录都存储在B+树的叶子节点,所有目录项记录都存储在内节点. InnoDB存储引擎会自动为主键(如果没有它会自动帮我们添加)建立聚簇索引,聚簇索引的叶子节点包含完整的用户记录. 我们可以为自己感兴趣的列建立二级索引,二级索引的叶子节点包含的用户记录由索引列 + 主键组成,所以如果想通过二级索引来查找完整的用户记录的话,需要通过回表操作,也就是在通过二级索引找到主键值之后再到聚簇索引中查找完整的用户记录. B

mysql性能优化之索引优化(转)

作为免费又高效的数据库,mysql基本是首选.良好的安全连接,自带查询解析.sql语句优化,使用读写锁(细化到行).事物隔离和多版本并发控制提高并发,完备的事务日志记录,强大的存储引擎提供高效查询(表记录可达百万级),如果是InnoDB,还可在崩溃后进行完整的恢复,优点非常多.即使有这么多优点,仍依赖人去做点优化,看书后写个总结巩固下,有错请指正. 完整的mysql优化需要很深的功底,大公司甚至有专门写mysql内核的,sql优化攻城狮,mysql服务器的优化,各种参数常量设定,查询语句优化,主

mysql B+树索引简述

一,查询B+树索引的流程 B+树索引找到叶节点,再找到对应的数据页,然后将数据页加载到内存中,通过二分查找Page Directory中的槽,查找出一个粗略的目录,然后根据槽的指针指向链表中的行记录,之后在链表中依次查找. 需要注意的地方是,B+树索引不能找到具体的一条记录,而是只能找到对应的页.把页从磁盘装入到内存中,再通过Page Directory进行二分查找,同时此二分查找也可能找不到具体的行记录(有可能会找到),只是能找到一个接近的链表中的点,再从此点开始遍历链表进行查找. 二,聚簇索