Mysql資料庫自增id、uuid與雪花id詳解

2023-02-28 18:02:17

概念介紹

三種主鍵

自增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的最終解決方案。

參考資料：https://www.jb51.net/article/276649.htm

總結

1、舊系統或者單部署系統，一般都採用自增主鍵，主要是便捷性考慮。優缺點如下：

優點：自增長欄位往往用integer bigint型別，最多佔8個位元組。索引與外來鍵所佔用的空間連帶減少，增刪改查效率高。業務變化，不影響，不需要更新主鍵。
缺點：無法轉移資料庫，比如把表中的一批資料轉移或附帶到另一個表中，那麼由於是自增長欄位，那麼會導致無法轉移，因為另外一個表可能已經存在部分資料，會造成主鍵衝突。自增長欄位的缺陷。業務資料的完整性，無法保證。

2、對於高並行業務型資料表，尤其是分散式部署架構，一般建議儘量使用業務主鍵，主要是考慮到查詢效率、安全性以及分表分庫等的情況，優缺點如下：

優點：可以轉移資料庫，最大化節省了空間，因為並沒有多增加一個非業務欄位做主鍵。可以保證業務邏輯的完整性。避免產生垃圾資料，銀行就是用業務欄位做主鍵的，雖然效率低，但是安全。

缺點：如果業務發生改變，有可能需要修改主鍵，舉例：國家A表用身份證號做主鍵，然後其他很多表中的身份證號這列都是來自身份證表A中的主鍵（即外來鍵），那麼如果身份證號升級，比如從1代升級到2代，那麼連帶的表的外來鍵的索引通通都得發生變化，效率極低因為會連帶更新一串用到這個外來鍵的表，可見用業務欄位做主鍵的話，要保證主鍵不經常變化。

到此這篇關於Mysql資料庫自增id、uuid與雪花id的文章就介紹到這了,更多相關Mysql自增id、uuid與雪花id內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！