关于mysql:再聊-MySQL-聚簇索引

5次阅读

共计 2025 个字符，预计需要花费 6 分钟才能阅读完成。

为什么是再次了解呢？因为松哥之前写过相干的文章介绍过聚簇索引，然而感觉还不够，因而明天想再来和小伙伴们聊一聊这个话题。

数据库的索引从不同的角度能够划分成不同的类型，聚簇索引便是其中一种。

聚簇索引英文是 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 表中的数据在磁盘中只可能保留一份，不可能保留两份，所以，在一个表中，聚簇索引只可能有一个，不可能有多个。

有的小伙伴搞不清楚这两者之间的关系，甚至将两者划等号，这是一个微小的误区。

在有的数据库中，反对开发者自在的抉择应用哪一个索引作为聚簇索引，然而 MySQL 中是不反对这个个性的。

在 MySQL 中，如果表自身就有设置主键，那么主键就是聚簇索引；如果表自身没有设置主键，则会抉择表中的一个惟一且非空的索引来作为聚簇索引；如果表中连惟一非空的索引都没有，那么就会主动抉择表中的隐式主键来作为聚簇索引。对于 MySQL 中表的隐式主键，松哥会在未来的文章中和大家介绍。

不过一般来说，还是倡议大家本人来为表设置主键，因为隐式主键是自增的，自增的都会存在一个问题：在自增值上会存在十分高的锁竞争问题，主键的上界会称为热点数据，因为所有的插入操作都要主键自增，又不能反复，所以会产生锁竞争进而导致性能升高。

依据下面的介绍，咱们能够总结出 MySQL 中聚簇索引和主键索引的关系如下：

先来说长处：

互相关联的数据咱们能够将之保留在一起。例如有一个用户订单表，咱们能够依据 用户 ID + 订单 ID 来汇集所有数据，用户 ID 可能会反复，订单 ID 则不会反复，这样咱们就可能将一个用户相干的订单数据都保留在一起，如果须要查问一个用户的所有订单，就会十分快，只须要大量的磁盘 IO 就能够做到。
不须要回表，因而数据访问速度更快。在聚簇索引中，索引和数据都在同一棵 B+Tree 上，因而从聚簇索引中获取到的数据比从非聚簇索引上获取数据更快（非聚簇索引须要回表）。
对于第一点的案例，如果咱们想依据用户 ID 查问到这个用户所有的订单 ID，那么此时都不必去到叶子结点了，因为支节点上就有咱们须要的数据，所以间接利用笼罩索引的个性，就能够读取到须要的数据。

这些就是聚簇索引一些常见的长处，咱们在日常的表设计中，其实应该充分利用好这些长处。

再来看看毛病：

小伙伴们发现，后面咱们说的聚簇索引的劣势次要是聚簇索引缩小了 IO 次数，从而进步了数据库的性能，然而有的 IO 密集型利用，可能间接上一个足够大的内存，把数据都读取到内存中操作，此时聚簇索引就没有啥劣势了。
随机主键会导致页决裂问题，主键程序插入的话，相对来说效率会高一些，因为在 B+Tree 中只须要一直往后面追加即可；然而主键如果是非程序插入的话，效率就会低很多，因为可能会波及到页决裂问题。以下面那张图为例，假如每个节点能够保留三条数据，当初咱们要插入一个主键是 4.5 的记录，那么就须要把主键为 5 的值往后挪动，进而导致主键为 8 的节点也要往后挪动。页决裂会导致数据插入效率升高并且占用更多的存储空间。
非聚簇索引（二级索引）查问的时候须要回表。因为一个索引就是一棵索引树，数据都在聚簇索引上，所以如果应用非聚簇索引进行搜寻，非聚簇索引的叶子上存储的是主键值，先找到主键值，而后拿着主键值再来聚簇索引上搜寻，这样一共就查问了两棵索引树，这就是回表。

看了下面的介绍，置信小伙伴曾经理解了，在应用聚簇索引的时候，主键最好不要应用 UUID 这种随机字符串，应用 UUID 随机字符串至多存在两方面的问题：