数据库主键为什么要用递增的序列？

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

作为主键的要求

  1. 程序
  2. 惟一
  3. 能短则短，缩小空间占用

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

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

UUID为什么不适宜做主键？

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

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

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

Java中的UUID

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);    }}