再聊 MySQL 聚簇索引

为什么是再次理解呢?因为松哥之前写过相关的文章介绍过聚簇索引,但是感觉还不够,因此今天想再来和小伙伴们聊一聊这个话题。

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 中聚簇索引和主键索引的关系如下:

  1. 聚簇索引不一定是主键索引。
  2. 主键索引一定是聚簇索引。

3. 聚簇索引优缺点

先来说优点:

  1. 相互关联的数据我们可以将之保存在一起。例如有一个用户订单表,我们可以根据 用户 ID + 订单 ID 来聚集所有数据,用户 ID 可能会重复,订单 ID 则不会重复,这样我们就能够将一个用户相关的订单数据都保存在一起,如果需要查询一个用户的所有订单,就会非常快,只需要少量的磁盘 IO 就可以做到。
  2. 不需要回表,因此数据访问速度更快。在聚簇索引中,索引和数据都在同一棵 B+Tree 上,因此从聚簇索引中获取到的数据比从非聚簇索引上获取数据更快(非聚簇索引需要回表)。
  3. 对于第一点的案例,如果我们想根据用户 ID 查询到这个用户所有的订单 ID,那么此时都不用去到叶子结点了,因为支节点上就有我们需要的数据,所以直接利用覆盖索引的特性,就可以读取到需要的数据。

这些就是聚簇索引一些常见的优点,我们在日常的表设计中,其实应该充分利用好这些优点。

再来看看缺点:

  1. 小伙伴们发现,前面我们说的聚簇索引的优势主要是聚簇索引减少了 IO 次数,从而提高了数据库的性能,但是有的 IO 密集型应用,可能直接上一个足够大的内存,把数据都读取到内存中操作,此时聚簇索引就没有啥优势了。
  2. 随机主键会导致页分裂问题,主键顺序插入的话,相对来说效率会高一些,因为在 B+Tree 中只需要不断往后面追加即可;但是主键如果是非顺序插入的话,效率就会低很多,因为可能会涉及到页分裂问题。以上面那张图为例,假设每个节点可以保存三条数据,现在我们要插入一个主键是 4.5 的记录,那么就需要把主键为 5 的值往后移动,进而导致主键为 8 的节点也要往后移动。页分裂会导致数据插入效率降低并且占用更多的存储空间。
  3. 非聚簇索引(二级索引)查询的时候需要回表。因为一个索引就是一棵索引树,数据都在聚簇索引上,所以如果使用非聚簇索引进行搜索,非聚簇索引的叶子上存储的是主键值,先找到主键值,然后拿着主键值再来聚簇索引上搜索,这样一共就查询了两棵索引树,这就是回表。

4. 最佳实践

看了上面的介绍,相信小伙伴已经了解了,在使用聚簇索引的时候,主键最好不要使用 UUID 这种随机字符串,使用 UUID 随机字符串至少存在两方面的问题:

  1. 插入效率低,因为插入可能会导致页分裂,这个前面已经说过了。
  2. UUID 字符串所占用的存储空间远远大于一个 bigint,如果使用 UUID 来做主键,意味着在二级索引中,一个叶子结点能够存储的主键值就非常有限,进而可能会导致树增高,搜索时候 IO 次数增多,性能下降。

所以相对来说,主键自增会优于 UUID。那么主键自增就是最完美的方案了吗?很多小伙伴可能也听说过一句话:没有银弹!所以,主键自增其实也有问题,具体什么问题,我们下便文章继续。

喜欢这篇文章吗?扫码关注公众号【江南一点雨】【江南一点雨】专注于 SPRING BOOT+微服务以及前后端分离技术,每天推送原创技术干货,关注后回复 JAVA,领取松哥为你精心准备的 JAVA 干货!

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×