学习笔记-深入浅出索引

一句话简单的来说,索引的出现其实就是为了提高数据查询的效率,就像书的目录一样。对于数据库的表而言,索引其实就是它的目录。

索引的常见模型

索引的出现是为了提高查询效率,但实现索引的方式却有很多种,所以这里也就引入了索引模型的概念。可以用于提高读写效率的数据结构有很多,这里介绍三种常见、比较简单的数据结构,他们是哈希表、有序数组、和搜索树。

从使用的角度,简单说下三种索引的区别。

哈希表是一种以key-value存储的数据结构。哈希的思路很简单,把value存放在数组里,用一个哈希函数把key换算成一个确定的位置。然后把value存放在数组的这个位置。
需要注意的是,hash的key并不是递增的,这样的好处是增加新的数据时速度会很快,只需要往后追加,缺点是,因为不是有序的,所以哈希索引做区间查询的速度是很慢的。
所以哈希这种结构只适用于只有等值查询的这种场景

而有序数组在范围查询和等值查询的场景中性能都非常优秀
如果仅仅看查询效率,有序数组就是最好的数据结构了,但是需要更新数据的时候就麻烦了,你往中间插一个记录就必须的挪动后面所有的记录,成本太高。
所以,有序数组只适用于静态存储引擎,比如你要保存的是2017年所有人口的信息。

二叉搜索树是课本里经典的数据结构了,结构不在赘述。
树可以有二叉,也可以有多叉,二叉树是搜索效率最高的,但实际上大多存储引擎并不使用二叉树,其原因是索引不仅存在内存中,还要写到磁盘上。
你可以想象一下,一颗100万节点的平衡二叉树,树高20,一次查询可能需要访问20个数据块。在机械硬盘的时代,从磁盘随机访问一个数据块大概需要10ms的寻址时间,使用二叉树存储,单独访问一个行可能需要20*10ms的时间。
为了让一个查询尽量的少读磁盘,就必须让查询查询过程访问尽量少的数据块。那么我们就不应该使用二叉树,而是使用“N叉树”,这个N取决于数据块的大小。

InnoDB的索引模型

在InnoDB中,表都是根据主键顺序以索引方式存放的,这种存储的方式表被称为索引组织表。InnoDB使用了B+树存储模型,所以索引都是存储在B+树中的。

每一个索引在DB里面对应一颗B+树。

假设我们有一个主键为ID的表,表中有字段K,并且在K上有索引。
这个表的建表语句是

mysql> create table T(
id int primary key, 
k int not null, 
name varchar(16),
index (k))engine=InnoDB;
InnoDB的索引组织结构

从图中不难看出,根据叶子节点的内容,索引类型分为主键索引和非主键索引。

主键索引的叶子节点存的是整行数据。在InnoDB里,主键索引也被称为聚簇索引(clustered index)。

非主键索引叶子节点内容是主键的值,在InnoDB里非主键索性也被称为二级索引。

基于上述结构,我们来讨论一个问题:基于主键索引和非主键索引的查询有什么区别

  • 如果语句是select * from T WHERE ID=500;即主键查询方式,则只需要搜索ID这棵B+树。
  • 如果查询语句是select * from T where k=5;即普通索引查询方式,则需要先搜索K索引树,得到ID的值为500,再到ID索引树搜索一次。这个过程称为回表。

也就是说基于非主键的索引要多扫描一颗索引树。因此,我们在应用中应该尽量使用主键索引。

索引维护

以上面这个图为例,如果新插入的行ID为700,则只需要在R5的后面插入一条新记录;如果新插入的值ID为400,则相对麻烦了,需要逻辑上挪动后面的数据,空出位置。
更糟糕的情况是,如果R5所在的数据页已经满了,这时候就需要申请一个新的数据页,挪动部分数据过去。这个过程称为页分裂。在这种情况下,性能会受到影响。
当然有分裂就会有合并,当相邻两个页由于删除了数据利用率很低后,会将数据页做合并。

基于上面的维护过程,我们来讨论一个问题:

你可能在一些建表规范里见过一些类似描述,要求建表语句里一定要有自增主键。当然事无绝对,我们来分析一下哪些场景下应该使用自增主键,而哪些场景下不应该。

  • 自增主键的插入模式,符合了我们前面提到的递增插入场景。不会触发页分裂。而业务逻辑字段作为主键,往往不容易保证由于插入,这样写数据的成本相对较高。
  • 除了考虑性能外,我们还可以从存储空间的角度来看。假设你的表中确实有一个唯一字段,比如字符串类型的身份证号,那应该用身份证号做主键,还是用自增主键呢?
    由于每个非主键索引叶子节点上都是主键索引的值。如果用身份证号做主键,那么每个二级索引的叶子节点占用约20个字节,而如果用整形做主键,则只需要4个字节。
    显然,主键长度越小,普通索引的叶子节点就越小,普通索引占用的空间也就越小。
    所以从性能和存储空间方面考量,自增主键往往是更合理的选择。

有没有什么场景适合用业务字段直接做主键的呢? 还是有的。比如有些业务场景需求是这样的:

  1. 只有一个索引;
  2. 该索引必须是唯一索引。
    你也一定看出来了,这就是典型的kv场景。由于没有其他索引,所以也就不用考虑其他索引的叶子节点大小问题。

延伸阅读
了解change buffer作用
感谢以下文章作者:
https://blog.csdn.net/shenjian58/article/details/93691224
https://www.lizenghai.com/archives/43575.html

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,732评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,496评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,264评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,807评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,806评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,675评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,029评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,683评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 41,704评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,666评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,773评论 1 332
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,413评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,016评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,978评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,204评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,083评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,503评论 2 343

推荐阅读更多精彩内容