Mysql數據庫自增id、uuid與雪花id實例分析

這篇“Mysql數據庫自增id、uuid與雪花id實例分析”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“Mysql數據庫自增id、uuid與雪花id實例分析”文章吧。

概念介紹

三種主鍵

自增id ：1 2 3 4 5……

uuid ：UUID是Universally Unique Identifier的縮寫，它是在一定的范圍內（從特定的名字空間到全球）唯一的機器生成的標識符。通用唯一標識符的意思，可以以業務實際user id為主鍵 比如QQ號 手機號等

雪花id ：相比UUID無序生成的id而言,雪花算法是有序的（有時間參數）,而且都是由數字組成。雪花id最大為64位,符合java中long的長度64位。適用于大規模分布式

聚簇索引與非聚簇索引

自增id

自增的主鍵的值是順序的,所以Innodb把每一條記錄都存儲在一條記錄的后面。當達到頁面的最大填充因子時候(innodb默認的最大填充因子是頁大小的15/16,會留出1/16的空間留作以后的 修改)：

①下一條記錄就會寫入新的頁中，一旦數據按照這種順序的方式加載，主鍵頁就會近乎于順序地記錄填滿，提升了頁面的最大填充率，不會有頁的浪費

②新插入的行一定會在原有的最大數據行下一行,mysql定位和尋址很快，不會為計算新行的位置而做出額外的消耗

③減少了頁分裂和碎片的產生

優點：

1.自增，趨勢自增，可作為聚集索引，提升查詢效率

2.節省磁盤空間。500W數據，UUID占5.4G,自增ID占2.5G.

3.查詢，寫入效率高：查詢略優。在數據量大時候 高于uuid插入速度

缺點：

1.導入舊數據時，可能會ID重復，導致導入失敗。

2.分布式架構，多個Mysql實例可能會導致ID重復。

3.容易被外界攻破，知道業務實際情況。且例如：顯示公告內容index?id=3這樣就很容易被人篡改為index?id=2.就可以調到第二條的內容。

4對于高并發的負載，innodb在按主鍵進行插入的時候會造成明顯的鎖爭用，主鍵的上界會成為爭搶的熱點，因為所有的插入都發生在這里，并發插入會導致間隙鎖競爭。Auto_Increment鎖機制會造成自增鎖的搶奪,有一定的性能損失

uuid

缺點看上面

雪花id與應用

面試官： 小伙子，你低著頭笑什么吶。開始面試了，你知道訂單ID是怎么生成的嗎？

我： 還能咋生成？用數據庫主鍵自增唄。

面試官： 這樣不行啊。數據庫主鍵順序自增，每天有多少訂單量被競爭對手看的一清二楚，商業機密都暴露了。況且單機MySQL只能支持幾百量級的并發，我們公司每天千萬訂單量，hold不住啊。

我： 嗯，那就用用數據庫集群，自增ID起始值按機器編號，步長等于機器數量。
比如有兩臺機器，第一臺機器生成的ID是1、3、5、7，第二臺機器生成的ID是2、4、6、8。性能不行就加機器，這并發量der一下就上去了。

面試官：小伙子，你想得倒是挺好。你有沒有想過實現百萬級的并發，大概就需要2000臺機器，你這還只是用來生成訂單ID，公司再有錢也經不起這么造。

我： 既然MySQL的并發量不行，我們是不是可以提前從MySQL獲取一批自增ID，加載到本地內存中，然后從內存中并發取，這并發性能豈不是杠杠滴。

面試官： 你還挺上道，這種叫號段模式。并發量是上去了，但是自增ID還是不能作為訂單ID的。

我： 用Java自帶UUID怎么樣？

import java.util.UUID;
/**
 * @author yideng
 * @apiNote UUID示例
 */
public class UUIDTest {
    public static void main(String[] args) {
        String orderId = UUID.randomUUID().toString().replace("-", "");
        System.out.println(orderId);
    }
}
輸出結果：
58e93ecab9c64295b15f7f4661edcbc1

面試官： 也不行。32位字符串會占用更大的空間，無序的字符串作數據庫主鍵，每次插入數據庫的時候，MySQL為了維護B+樹結構，需要頻繁調整節點順序，影響性能。況且字符串太長，也沒有任何業務含義，pass。
小伙子，你可能是沒參與過電商系統，我先跟說一下生成訂單ID要滿足哪些條件：
全局唯一：如果訂單ID重復了，肯定要完蛋。 高性能：要做到高并發、低延遲。生成訂單ID都成為瓶頸了，那還得了。
高可用：至少要做到4個9，別動不動就宕機了。 易用性：如果為了滿足上述要求，搞了幾百臺服務器，復雜且難以維護，也不行。
數值且有序遞增：數值占用的空間更小，有序遞增能保證插入MySQL的時候更高性能。
嵌入業務含義：如果訂單ID里面能嵌入業務含義，就能通過訂單ID知道是哪個業務線生成的，便于排查問題。

我： 我聽說圈內有一種流傳已久的分布式、高性能、高可用的訂單ID生成算法—雪花算法，完全能滿足你的上述要求。雪花算法生成ID是Long類型，長度64位。

第 1 位： 符號位，暫時不用。

第 2~42 位： 共41位，時間戳，單位是毫秒，可以支撐大約69年

第 43~52 位： 共10位，機器ID，最多可容納1024臺機器

第 53~64 位： 共12位，序列號，是自增值，表示同一毫秒內產生的ID，單臺機器每毫秒最多可生成4096個訂單ID

接入非常簡單，不需要搭建服務集群，。代碼邏輯非常簡單，，同一毫秒內，訂單ID的序列號自增。同步鎖只作用于本機，機器之間互不影響，每毫秒可以生成四百萬個訂單ID，非常強悍。

生成規則不是固定的，可以根據自身的業務需求調整。如果你不需要那么大的并發量，可以把機器標識位拆出一部分，當作業務標識位，標識是哪個業務線生成的訂單ID。

面試官： 小伙子，有點東西，深藏不漏啊。再問個更難的問題，你覺得雪花算法還有改進的空間嗎？

你真是打破砂鍋問到底，不把我問趴下不結束。幸虧來之前我瞥了一眼一燈的文章。

我： 有的，雪花算法嚴重依賴系統時鐘。如果時鐘回撥，就會生成重復ID。

面試官： 有什么解決辦法嗎？

我： 有問題就會有答案。比如美團的Leaf（美團自研一種分布式ID生成系統），為了解決時鐘回撥，引入了zookeeper，原理也很簡單，就是比較當前系統時間跟生成節點的時間。

有的對并發要求更高的系統，比如雙十一秒殺，每毫秒4百萬并發還不能滿足要求，就可以使用雪花算法和號段模式相結合，比如百度的UidGenerator、滴滴的TinyId。想想也是，號段模式的預先生成ID肯定是高性能分布式訂單ID的最終解決方案。

以上就是關于“Mysql數據庫自增id、uuid與雪花id實例分析”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。