关于mysql:数据库主键为什么要用递增的序列UUID为什么不适合做主键

7次阅读

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

程序的 ID 占用的空间比随机 ID 占用的空间小。
起因是数据库主键和索引索引应用 B + 树的数据结构进行存储，程序 ID 数据存储在最初一个节点的最初的地位，后面的节点数据都是满的。随机 ID 存储时可能会呈现节点决裂，导致节点多了，然而每个节点的数据量少了，存储到文件系统中时，无论节点中数据是不是满的都会占用一页的空间。所以所导致空间占用较大。

程序
惟一
能短则短，缩小空间占用

自增的 ID 能够满足大部分业务场景，然而在一些非凡场景中并不适合，只举局部例子

分布式系统中
分库分表的数据库设计
存在一些平安问题，对于一些敏感信息容易被揣测。

UUID 值由本机 Mac 地址和工夫戳等因素决定，UUID 呈现反复概率极简直能够忽略不计。

如果需要是只保障唯一性，那么 UUID 也是能够应用的，然而依照下面的分布式 id 的要求，UUID 其实是不能做成分布式 id 的，起因如下：

首先分布式 id 个别都会作为主键，然而 mysql 官网举荐主键要尽量越短越好，UUID 每一个都很长，所以不是很举荐
既然分布式 id 是主键，而后主键是蕴含索引的，而后 mysql 的索引是通过 b + 树来实现的，每一次新的 UUID 数据的插入，为了查问的优化，都会对索引底层的 b + 树进行批改，因为 UUID 数据是无序的，所以每一次 UUID 数据的插入都会对主键地城的 b + 树进行很大的批改，这一点很不好
信息不平安：基于 MAC 地址生成 UUID 的算法可能会造成 MAC 地址泄露，这个破绽曾被用于寻找梅丽莎病毒的制作者地位。

package com.one.util;
import java.util.UUID;
public class Test {public static void main(String[] args) {String uuid= UUID.randomUUID().toString().replace("-", "").toLowerCase();
        System.out.println("UUID 的值是:"+uuid);
    }
}

正文完