开启掘金成长之旅！这是我参与「掘金日新计划 · 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的交互次数。

今天先学习到这里，明天继续。