共计 2025 个字符,预计需要花费 6 分钟才能阅读完成。
为什么是再次了解呢?因为松哥之前写过相干的文章介绍过聚簇索引,然而感觉还不够,因而明天想再来和小伙伴们聊一聊这个话题。
1. 什么是聚簇索引
数据库的索引从不同的角度能够划分成不同的类型,聚簇索引便是其中一种。
聚簇索引英文是 Clustered Index,有时候小伙伴们可能也会看到有人将之称为汇集索引等,与之绝对的是非聚簇索引或者二级索引。
聚簇索引并不是一种独自的索引类型,而是一种数据的存储形式。在 MySQL 的 InnoDB 存储引擎中,所谓的聚簇索引实际上就是在同一个 B+Tree 中保留了索引和数据行: 此时,数据放在叶子结点中,聚簇聚簇,意思就是说数据行和对应的键值紧凑的存在一起。
假如我有如下数据:
id(主键) | username | age | address | gender |
---|---|---|---|---|
1 | ab | 99 | 深圳 | 男 |
2 | ac | 98 | 广州 | 男 |
3 | af | 88 | 北京 | 女 |
4 | bc | 80 | 上海 | 女 |
5 | bg | 85 | 重庆 | 女 |
6 | bw | 95 | 天津 | 男 |
7 | bw | 99 | 海口 | 女 |
8 | cc | 92 | 武汉 | 男 |
9 | ck | 90 | 深圳 | 男 |
10 | cx | 93 | 深圳 | 男 |
那么它的聚簇索引大略就是这个样子:
那么大家能够看到,叶子上既有主键值(索引)又有数据行,节点上则只有主键值(索引)。
小伙伴们想想,MySQL 表中的数据在磁盘中只可能保留一份,不可能保留两份,所以,在一个表中,聚簇索引只可能有一个,不可能有多个。
2. 聚簇索引和主键
有的小伙伴搞不清楚这两者之间的关系,甚至将两者划等号,这是一个微小的误区。
在有的数据库中,反对开发者自在的抉择应用哪一个索引作为聚簇索引,然而 MySQL 中是不反对这个个性的。
在 MySQL 中,如果表自身就有设置主键,那么主键就是聚簇索引;如果表自身没有设置主键,则会抉择表中的一个惟一且非空的索引来作为聚簇索引;如果表中连惟一非空的索引都没有,那么就会主动抉择表中的隐式主键来作为聚簇索引。对于 MySQL 中表的隐式主键,松哥会在未来的文章中和大家介绍。
不过一般来说,还是倡议大家本人来为表设置主键,因为隐式主键是自增的,自增的都会存在一个问题:在自增值上会存在十分高的锁竞争问题,主键的上界会称为热点数据,因为所有的插入操作都要主键自增,又不能反复,所以会产生锁竞争进而导致性能升高。
依据下面的介绍,咱们能够总结出 MySQL 中聚簇索引和主键索引的关系如下:
- 聚簇索引不肯定是主键索引。
- 主键索引肯定是聚簇索引。
3. 聚簇索引优缺点
先来说长处:
- 互相关联的数据咱们能够将之保留在一起。例如有一个用户订单表,咱们能够依据 用户 ID + 订单 ID 来汇集所有数据,用户 ID 可能会反复,订单 ID 则不会反复,这样咱们就可能将一个用户相干的订单数据都保留在一起,如果须要查问一个用户的所有订单,就会十分快,只须要大量的磁盘 IO 就能够做到。
- 不须要回表,因而数据访问速度更快。在聚簇索引中,索引和数据都在同一棵 B+Tree 上,因而从聚簇索引中获取到的数据比从非聚簇索引上获取数据更快(非聚簇索引须要回表)。
- 对于第一点的案例,如果咱们想依据用户 ID 查问到这个用户所有的订单 ID,那么此时都不必去到叶子结点了,因为支节点上就有咱们须要的数据,所以间接利用笼罩索引的个性,就能够读取到须要的数据。
这些就是聚簇索引一些常见的长处,咱们在日常的表设计中,其实应该充分利用好这些长处。
再来看看毛病:
- 小伙伴们发现,后面咱们说的聚簇索引的劣势次要是聚簇索引缩小了 IO 次数,从而进步了数据库的性能,然而有的 IO 密集型利用,可能间接上一个足够大的内存,把数据都读取到内存中操作,此时聚簇索引就没有啥劣势了。
- 随机主键会导致页决裂问题,主键程序插入的话,相对来说效率会高一些,因为在 B+Tree 中只须要一直往后面追加即可;然而主键如果是非程序插入的话,效率就会低很多,因为可能会波及到页决裂问题。以下面那张图为例,假如每个节点能够保留三条数据,当初咱们要插入一个主键是 4.5 的记录,那么就须要把主键为 5 的值往后挪动,进而导致主键为 8 的节点也要往后挪动。页决裂会导致数据插入效率升高并且占用更多的存储空间。
- 非聚簇索引(二级索引)查问的时候须要回表。因为一个索引就是一棵索引树,数据都在聚簇索引上,所以如果应用非聚簇索引进行搜寻,非聚簇索引的叶子上存储的是主键值,先找到主键值,而后拿着主键值再来聚簇索引上搜寻,这样一共就查问了两棵索引树,这就是回表。
4. 最佳实际
看了下面的介绍,置信小伙伴曾经理解了,在应用聚簇索引的时候,主键最好不要应用 UUID 这种随机字符串,应用 UUID 随机字符串至多存在两方面的问题:
- 插入效率低,因为插入可能会导致页决裂,这个后面曾经说过了。
- UUID 字符串所占用的存储空间远远大于一个 bigint,如果应用 UUID 来做主键,意味着在二级索引中,一个叶子结点可能存储的主键值就十分无限,进而可能会导致树增高,搜寻时候 IO 次数增多,性能降落。
所以相对来说,主键自增会优于 UUID。那么主键自增就是最完满的计划了吗?很多小伙伴可能也据说过一句话:没有银弹!所以,主键自增其实也有问题,具体什么问题,咱们下便文章持续。