快捷導(dǎo)航

Mysql數(shù)據(jù)庫(kù)自增id、uuid與雪花id詳解

更新時(shí)間：2023年02月28日 10:34:11 作者：云閑不收

在mysql中設(shè)計(jì)表的時(shí)候,mysql官方推薦不要使用uuid或者不連續(xù)不重復(fù)的雪花id(long形且唯一),而是推薦連續(xù)自增的主鍵id,這篇文章主要給大家介紹了關(guān)于Mysql數(shù)據(jù)庫(kù)自增id、uuid與雪花id的相關(guān)資料,需要的朋友可以參考下

概念介紹

三種主鍵

自增id ：1 2 3 4 5……

uuid ：UUID是Universally Unique Identifier的縮寫，它是在一定的范圍內(nèi)（從特定的名字空間到全球）唯一的機(jī)器生成的標(biāo)識(shí)符。通用唯一標(biāo)識(shí)符的意思，可以以業(yè)務(wù)實(shí)際user id為主鍵比如QQ號(hào) 手機(jī)號(hào)等

雪花id ：相比UUID無序生成的id而言,雪花算法是有序的（有時(shí)間參數(shù)）,而且都是由數(shù)字組成。雪花id最大為64位,符合java中l(wèi)ong的長(zhǎng)度64位。適用于大規(guī)模分布式

聚簇索引與非聚簇索引

自增id

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

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

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

③減少了頁(yè)分裂和碎片的產(chǎn)生

優(yōu)點(diǎn)：

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

2.節(jié)省磁盤空間。500W數(shù)據(jù)，UUID占5.4G,自增ID占2.5G.

3.查詢，寫入效率高：查詢略優(yōu)。在數(shù)據(jù)量大時(shí)候高于uuid插入速度

缺點(diǎn)：

1.導(dǎo)入舊數(shù)據(jù)時(shí)，可能會(huì)ID重復(fù)，導(dǎo)致導(dǎo)入失敗。

2.分布式架構(gòu)，多個(gè)Mysql實(shí)例可能會(huì)導(dǎo)致ID重復(fù)。

3.容易被外界攻破，知道業(yè)務(wù)實(shí)際情況。且例如：顯示公告內(nèi)容index?id=3這樣就很容易被人篡改為index?id=2.就可以調(diào)到第二條的內(nèi)容。

4對(duì)于高并發(fā)的負(fù)載，innodb在按主鍵進(jìn)行插入的時(shí)候會(huì)造成明顯的鎖爭(zhēng)用，主鍵的上界會(huì)成為爭(zhēng)搶的熱點(diǎn)，因?yàn)樗械牟迦攵及l(fā)生在這里，并發(fā)插入會(huì)導(dǎo)致間隙鎖競(jìng)爭(zhēng)。Auto_Increment鎖機(jī)制會(huì)造成自增鎖的搶奪,有一定的性能損失

uuid

缺點(diǎn)看上面

雪花id與應(yīng)用

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

我：還能咋生成？用數(shù)據(jù)庫(kù)主鍵自增唄。

面試官：這樣不行啊。數(shù)據(jù)庫(kù)主鍵順序自增，每天有多少訂單量被競(jìng)爭(zhēng)對(duì)手看的一清二楚，商業(yè)機(jī)密都暴露了。況且單機(jī)MySQL只能支持幾百量級(jí)的并發(fā)，我們公司每天千萬訂單量，hold不住啊。

我：嗯，那就用用數(shù)據(jù)庫(kù)集群，自增ID起始值按機(jī)器編號(hào)，步長(zhǎng)等于機(jī)器數(shù)量。
比如有兩臺(tái)機(jī)器，第一臺(tái)機(jī)器生成的ID是1、3、5、7，第二臺(tái)機(jī)器生成的ID是2、4、6、8。性能不行就加機(jī)器，這并發(fā)量der一下就上去了。

面試官：小伙子，你想得倒是挺好。你有沒有想過實(shí)現(xiàn)百萬級(jí)的并發(fā)，大概就需要2000臺(tái)機(jī)器，你這還只是用來生成訂單ID，公司再有錢也經(jīng)不起這么造。

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

面試官：你還挺上道，這種叫號(hào)段模式。并發(fā)量是上去了，但是自增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);
    }
}
輸出結(jié)果：
58e93ecab9c64295b15f7f4661edcbc1

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

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

第 1 位：符號(hào)位，暫時(shí)不用。

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

第 43~52 位：共10位，機(jī)器ID，最多可容納1024臺(tái)機(jī)器

第 53~64 位：共12位，序列號(hào)，是自增值，表示同一毫秒內(nèi)產(chǎn)生的ID，單臺(tái)機(jī)器每毫秒最多可生成4096個(gè)訂單ID

接入非常簡(jiǎn)單，不需要搭建服務(wù)集群，。代碼邏輯非常簡(jiǎn)單，，同一毫秒內(nèi)，訂單ID的序列號(hào)自增。同步鎖只作用于本機(jī)，機(jī)器之間互不影響，每毫秒可以生成四百萬個(gè)訂單ID，非常強(qiáng)悍。

生成規(guī)則不是固定的，可以根據(jù)自身的業(yè)務(wù)需求調(diào)整。如果你不需要那么大的并發(fā)量，可以把機(jī)器標(biāo)識(shí)位拆出一部分，當(dāng)作業(yè)務(wù)標(biāo)識(shí)位，標(biāo)識(shí)是哪個(gè)業(yè)務(wù)線生成的訂單ID。

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

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

我：有的，雪花算法嚴(yán)重依賴系統(tǒng)時(shí)鐘。如果時(shí)鐘回?fù)?，就?huì)生成重復(fù)ID。

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

我：有問題就會(huì)有答案。比如美團(tuán)的Leaf（美團(tuán)自研一種分布式ID生成系統(tǒng)），為了解決時(shí)鐘回?fù)埽肓藌ookeeper，原理也很簡(jiǎn)單，就是比較當(dāng)前系統(tǒng)時(shí)間跟生成節(jié)點(diǎn)的時(shí)間。

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

參考資料：http://www.dbjr.com.cn/article/276649.htm

總結(jié)

1、舊系統(tǒng)或者單部署系統(tǒng)，一般都采用自增主鍵，主要是便捷性考慮。優(yōu)缺點(diǎn)如下：

優(yōu)點(diǎn)：自增長(zhǎng)字段往往用integer bigint類型，最多占8個(gè)字節(jié)。索引與外鍵所占用的空間連帶減少，增刪改查效率高。業(yè)務(wù)變化，不影響，不需要更新主鍵。
缺點(diǎn)：無法轉(zhuǎn)移數(shù)據(jù)庫(kù)，比如把表中的一批數(shù)據(jù) 轉(zhuǎn)移或附帶到另一個(gè)表中，那么由于是自增長(zhǎng)字段，那么會(huì)導(dǎo)致無法轉(zhuǎn)移，因?yàn)榱硗庖粋€(gè)表可能已經(jīng)存在部分?jǐn)?shù)據(jù)，會(huì)造成主鍵沖突。自增長(zhǎng)字段的缺陷。業(yè)務(wù)數(shù)據(jù)的完整性，無法保證。

2、對(duì)于高并發(fā)業(yè)務(wù)型數(shù)據(jù)表，尤其是分布式部署架構(gòu)，一般建議盡量使用業(yè)務(wù)主鍵，主要是考慮到查詢效率、安全性以及分表分庫(kù)等的情況，優(yōu)缺點(diǎn)如下：

優(yōu)點(diǎn)：可以轉(zhuǎn)移數(shù)據(jù)庫(kù)，最大化節(jié)省了空間，因?yàn)椴]有多增加一個(gè)非業(yè)務(wù)字段做主鍵?？梢员ＷC業(yè)務(wù)邏輯的完整性。避免產(chǎn)生垃圾數(shù)據(jù)，銀行就是用業(yè)務(wù)字段做主鍵的，雖然效率低，但是安全。

缺點(diǎn)：如果業(yè)務(wù)發(fā)生改變，有可能需要修改主鍵，舉例：國(guó)家A表用身份證號(hào)做主鍵，然后其他很多表中的身份證號(hào)這列都是來自身份證表A中的主鍵（即外鍵），那么如果身份證號(hào)升級(jí)，比如從1代升級(jí)到2代，那么連帶的表的外鍵的索引通通都得發(fā)生變化，效率極低因?yàn)闀?huì)連帶更新一串用到這個(gè)外鍵的表，可見用業(yè)務(wù)字段做主鍵的話，要保證主鍵不經(jīng)常變化。

到此這篇關(guān)于Mysql數(shù)據(jù)庫(kù)自增id、uuid與雪花id的文章就介紹到這了,更多相關(guān)Mysql自增id、uuid與雪花id內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: