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

  • 每个索引都对应一棵B+树,B+树分为好多层,最下边一层是叶子节点,其余的是内节点。所有用户记录都存储在B+树的叶子节点,所有目录项记录都存储在内节点。
  • InnoDB存储引擎会自动为主键(如果没有它会自动帮我们添加)建立聚簇索引,聚簇索引的叶子节点包含完整的用户记录。
  • 我们可以为自己感兴趣的列建立二级索引二级索引的叶子节点包含的用户记录由索引列 + 主键组成,所以如果想通过二级索引来查找完整的用户记录的话,需要通过回表操作,也就是在通过二级索引找到主键值之后再到聚簇索引中查找完整的用户记录。
  • B+树中每层节点都是按照索引列值从小到大的顺序排序而组成了双向链表,而且每个页内的记录(不论是用户记录还是目录项记录)都是按照索引列的值从小到大的顺序而形成了一个单链表。如果是联合索引的话,则页面和记录先按照联合索引前边的列排序,如果该列值相同,再按照联合索引后边的列排序。
  • 通过索引查找记录是从B+树的根节点开始,一层一层向下搜索。由于每个页面都按照索引列的值建立了Page Directory(页目录),所以在这些页面中的查找非常

首先我们需要知道在innoDB中一条记录的格式:

将记录格式的其他信息去掉并把它竖起来的效果就是这样

把一些记录放到页里边的示意图就是:

注意record_type的取值不同,代表着该条记录有不同的含义:

一个页面里面里的记录通过next_record指针串成一个链表,为了查找方便,为这个链表设置了两个虚拟头节点: 最小记录和最大记录:

record_type = 1表示是最小记录,record_type = 3表示是最大记录。

record_type = 0表示是普通用户记录。

record_type = 2表示是索引项目记录。这个后面再说。

页分裂

假设我们的每个数据页最多能存放3条记录(实际上一个数据页非常大,可以存放下好多记录),innoDB在插入数据项的时候,会按照主键值的大小顺序串联成一个单向链表:

上图中的三条记录按照主键(橙色)由小到大的顺序串成一个链表

此时我们再插入一条记录,因为页10最多只能放3条记录,所以我们不得不再分配一个新页:

页10中用户记录最大的主键值是5,而页28中有一条记录的主键值是4,因为5 > 4,所以这就不符合下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值的要求,所以在插入主键值为4的记录的时候需要伴随着一次记录移动,也就是把主键值为5的记录移动到页28中,然后再把主键值为4的记录插入到页10中。我们必须通过一些诸如记录移动的操作来始终保证这个状态一直成立:下一个数据页中用户记录的主键值必须大于上一个页中用户记录的主键值。这个过程我们也可以称为页分裂


    • B+树索引在空间和时间上都有代价,所以没事儿别瞎建索引。
    • B+树索引适用于下边这些情况:
      • 全值匹配
      • 匹配左边的列
      • 匹配范围值
      • 精确匹配某一列并范围匹配另外一列
      • 用于排序
      • 用于分组
    • 在使用索引时需要注意下边这些事项:
      • 只为用于搜索、排序或分组的列创建索引
      • 为列的基数大的列创建索引
      • 索引列的类型尽量小
      • 可以只对字符串值的前缀建立索引
      • 只有索引列在比较表达式中单独出现才可以适用索引
      • 为了尽可能少的让聚簇索引发生页面分裂和记录移位的情况,建议让主键拥有AUTO_INCREMENT属性。
      • 定位并删除表中的重复和冗余索引
      • 尽量使用覆盖索引进行查询,避免回表带来的性能损耗。

其他的部分见掘金小册!

原文地址:https://www.cnblogs.com/greatLong/p/10699792.html

时间: 2024-08-04 03:29:33

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

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树索引

聚集索引: 简单概念:一个表中根据主键创建的一棵B+树,索引的叶子节点存放了表中所有的记录,存储记录在物理位置上是连续的,一个叶子节点存放一条对应的记录(PS:是根据主键创建的B+树,叶子节点存数据记录) . 举个例子(以汉语字典为例): 汉语字典的正文本身就是一个聚集索引,比如我们要查"安"字,由于汉语词典的拼音排序是从"a"开始到"z"结尾的,则"安"字自然而然就排在字典前部,若翻遍了所有以"a"开头的

读掘金小册组件精讲总结1

1.组件分类 (1)由 vue-router 产生的每个页面,它本质上也是一个组件(.vue),主要承载当前页面的 HTML 结构,会包含数据获取.数据整理.数据可视化等常规业务.整个文件相对较大,但一般不会有 props 选项和 自定义事件,因为它作为路由的渲染,不会被复用,因此也不会对外提供接口. (2)不包含业务,独立.具体功能的基础组件,比如日期选择器.登录注册弹窗.toast等.这类组件作为项目的基础控件,会被大量使用,因此组件的 API 进行过高强度的抽象,可以通过不同配置实现不同的

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

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