开启掘金成长之旅!这是我参与「掘金日新计划 · 12 月更文挑战」的第20天,点击查看活动详情
前言
上篇我们学习了MySQL中的数据库优化之索引优化。有兴趣的小伙伴可以阅读(MySQL优化之索引优化(十))。
下面我们继续学习MySQL中的数据库优化之索引优化。
推荐的主键设计
非核心业务:对应表的主键自增ID,如告警、日志、监控等信息。
核心业务:主键设计至少应该是全局唯一且是单调递增。全局唯一保证在各系统之间都是唯一的,单调递增是希望插入时不影响数据库性能。推荐使用UUID。
UUID的特点:
全局唯一,占用36字节,数据无序,插入性能差。
MySQL数据库的UUID组成如下:
UUID=时间+UUID(版本)(16字节)- 时钟序列(4字节)- MAC地址(12字节)
为什么UUID是全局唯一的?
在UUID中时间部分占用60位,存储的类似TIMESTAMP的时间戳,但表示的是从1582-10-15 00:00:00.00到现在的100ns的计数,可以看到UUID存储的时间精度比TIMESTAMP更高,时间维度发生重复的概率降低到1/100ns。时钟序列是为了避免时钟被回拨导致产生时间重复的可能性。MAC地址用于全局唯一。
为什么UUID占用36字节?
UUID根据字符串进行存储,设计时还带有-字符串,因此总共需要36字节。
为什么UUID是随机无序的呢?
因为UUID设计中,将时间低位放在最前面,而这部分的数据是一直变化的,并且是无序的。
改造UUID
如果将时间高低位互换,则时间就是单调递增了,也就变成单调递增了。MySQL8.0可以更换时间低位和时间高位的存储方式,这样UUID就是有序的UUID了。
MySQL8.0还解决了UUID存在的空间占用的问题,除去了UUID字符串中无意义的-字符串,并且将字符串用二进制类型保存,这样存储空间降低为了16字节。
可以通过MySQL8.0的uuid_to_bin函数实现上述功能,同样的,MySQL也提供了bin_to_uuid函数进行转化。
有序的UUID性能是最快的,实际业务中UUID可以在业务端生成。还可以进一步减少SQL的交互次数。
今天先学习到这里,明天继续。