关于后端:大白话mysql之深入浅出索引原理-上

35次阅读

共计 2946 个字符,预计需要花费 8 分钟才能阅读完成。

当咱们应用汉语字典查找某个字时,咱们会先通过拼音目录查到那个字所在的页码,而后间接翻到字典的那一页,找到咱们要查的字,通过拼音目录查找比咱们拿起字典从头一页一页翻找要快的多,数据库索引也一样,索引就像书的目录,通过索引能极大进步数据查问的效率。

索引的实现形式

在数据库中,常见的索引实现形式有哈希表、有序数组、搜寻树。

哈希表

哈希表是通过键值对(key-value)存储数据的索引实现形式,能够将哈希表设想成是一个数组,将索引通过哈希函数计算失去该行数据在数组中的地位,而后将数据存到数组中,容易发现一个问题,如果两个索引通过哈希函数计算后失去的数组地位雷同要怎么办?咱们能够采纳哈希链表,数组的每个 value 都是一个链表,新数据间接增加到链表尾部。

所以数据库查问过程为:索引通过哈希函数计算数据所在位置 –> 遍历指定地位的链表,找到满足条件的数据。

每次有新数据退出时,新数据时间接增加到链表尾部,所以增加数据时很不便。

哈希表不善于进行区间查问,个别都用于等值查问,因为两个相邻索引通过 hash 函数后计算失去的数组地位不肯定还放弃相邻,须要哈希屡次能力把区间的数据全查出来。

有序数组

顾名思义,有序数组是按索引大小将数据保留在一个数组上,因为该数组是有序的,能够通过二分法很容易查到地位,找到第一个地位后,通过向左或者向右遍历很容易失去所求区间的数据。因而,无论是等值查问还是区间查问,效率都极高。

但缺点也是不言而喻的,当向数组两头 n 地位插入一条数据时,需将 n 前面的数据全副往后挪动,所以,这种索引个别用于动态存储引擎。

搜寻树

二叉搜寻树:一棵空树,或者是具备下列性质的二叉树:若它的左子树不空,则左子树上所有结点的值均小于它的根结点的值;若它的右子树不空,则右子树上所有结点的值均大于它的根结点的值;二叉搜寻树的左、右子树也别离为二叉搜寻树。

均衡二叉树:均衡二叉树是在二叉搜寻树的根底上引入的,指的是结点的左子树和右子树的深度差不超过 1。

多叉树:每个结点能够有多个子结点,子节点的大小从左到右顺次递增。

数据库个别应用均衡树来当索引的存储数据结构,当应用均衡二叉实现索引时,构造如下图。

从图中可发现,每次查问最多须要拜访 4 个节点必能失去所要数据。例如查问 user2 时,查问过程为:userA–>userC–>userF–>user2。所以查问速度很高,复杂度为 O (log (n));均衡二叉树的更新复杂度也为 O (log (n))。

区间查问时,因为搜寻树的个性(左子树小于右子树),能够很快的排除掉不满足条件的节点,查起来速度也是很快的。

思考下为什么用均衡搜寻树呢?

因为一般的二叉树可能因为插入的数据最初变成一个很长的链表,查问复杂度进化成 O (n)。

如果搜寻树存于内存中,与多叉树相比,二叉树的搜寻速率是最高的,但实际上数据库应用的是 n 叉树而不是二叉树。

  • 索引不仅存于内存,还是写到磁盘上,搜寻树上的每个结点在磁盘上体现为一个数据块。
  • 多叉树每个结点下能够有多个子节点,所以存储雷同数据量时多叉树的树高比二叉树小,查问一个数据须要拜访的结点数更少,即查问过程拜访更少的数据块。查问速度较高。

在 mysql 的 innodb 引擎中,应用 B + 树来存储数据,B + 树是一种多叉均衡查找树。

innodb 的索引模型

在 B + 树中,咱们将节点分为叶子结点和非叶子结点,非叶子结点上保留的是索引,而且一个节点能够保留多个索引;数据全副存于叶子结点上,并且叶子结点之间通过指针连接起来。

依据叶子结点的内容不同,innodb 索引分为主键索引和非主键索引。非主键索引也称为二级索引。主键索引的叶子结点中保留的数据为整行数据,而非主键索引叶子节点保留的是主键的值。

通过主键索引查问数据时,咱们只需查找主键索引树便能够获取数据;通过非主键索引查问数据时,咱们先通过非主键索引树查找到主键值,而后再在主键索引树搜寻一次,这个过程称为回表,也就是说非主键索引查问会比主键查问多搜寻一棵树。所以咱们应尽可能应用主键查问。

B + 树是一颗 N 叉树,N 是由什么决定的?是否调整?

  • 通过批改 page 的大小来间接调整 N 的大小。 一个节点上的所有数据都在一个 page 中 ,页越大,每页寄存的索引就越多,N 就越大。数据页调整后,如果数据页太小层数会太深,数据页太大,加载到内存的工夫和单个数据页查问工夫会进步,须要达到均衡才行。
  • 批改索引的大小。每个索引包含固定字节数的 Point 指针和索引字段内容,索引字段越小,每页能存的索引就越多,N 就越大。

索引保护

增加新行时,将会在索引表上增加一条记录,如果是索引递增插入时,数据都是追加在以后最大索引之后,不会对树中其余数据造成影响;如果新退出的数据的索引值位于节点的两头,须要移动局部节点的地位,从而放弃索引树的有序性。

而且,相邻多个节点是存储在同一个数据页上的,此时,如果是在曾经存储满状态的数据页中插入节点,会申请新的数据页,将局部数据移动到新的数据页,这个过程称为页决裂,页决裂除了会影响性能,还会升高磁盘空间利用率。不规则数据插入时,会造成频繁的页决裂。所以,个别状况下会采纳递增主键,使新数据递增插入。

当相邻两个页因为删除了数据,利用率很低之后,会将数据页做合并。

什么状况下应该应用业务逻辑字段做主键?有什么优缺点?

  • 业务逻辑字段不容易保障索引树结点有序插入,这样写入老本较高。
  • innodb 默认应用整数类型作为主键,主键长度较小,二级索引的叶子结点中保留的是主键值,主键长度越小,二级索引的叶子结点占用空间也就越小。
  • 当然,应用业务逻辑字段做主键也有益处,能够防止回表,每次只需扫描一次主键索引树即可。

综上,从性能和存储空间方面考量,自增主键往往是更正当的抉择,然而当业务场景有且只有一个索引,而且该索引为惟一索引时,此时更适宜应用业务逻辑字段作为主键,一个是防止回表,还有一个是只有一个索引也不须要思考二级索引的空间占用状况了。

索引重建

因为数据批改、删除、页决裂等起因,会导致数据页空间利用率升高,此时,能够思考重建索引,将数据按程序插入,进步磁盘空间利用率。

重建一般索引时,间接先删除索引,再从新创立即可。

alter table T drop index k; 
alter table T add index(k);

主键索引不能通过下面的语句去重建,因为删除主键索引后,innodb 会如下解决:

  • 如果存在非空且字段类型为数值的惟一索引(INT and NOT NULL and UNIQUE INDEX),会将第一个满足条件的索引作为主键索引 , _rowid 为对应主键,值与惟一索引雷同。(可通过 select _rowid from table 查问 )。
  • 如果找不到适合的索引,那么 InnoDB 会主动生成一个不可见的名为 ROW_ID 的列名为 GEN_CLUST_INDEX 的主键索引,该列是一个 6 字节的自增数值,随着插入而自增。

所以删除主键索引的后果其实是批改了主键字段,而一般索引的叶子节点存的是主键的值,所以,一旦批改了主键字段,一般索引也会有影响,叶子节点的值将被批改成新的主键字段。

当主键索引须要重建时,更好的做法是间接应用 alter table t engine=innodb 重建表。

写在最初

喜爱本文的敌人,欢送关注公众号「会玩 code」,专一大白话分享实用技术

正文完
 0