數據庫主鍵爲何要用遞增的序列？UUID爲何不適合作主鍵？

數據庫主鍵爲何要用遞增的序列？

順序的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);
    }
}