被追著問UUID和自增ID做主鍵哪個(gè)好,為什么?
之前無意間看到群友討論到用什么做主鍵比較好
圖片
圖片
圖片
其實(shí) UUID 和自增主鍵 ID 是常用于數(shù)據(jù)庫主鍵的兩種方式,各自具有獨(dú)特的優(yōu)缺點(diǎn)。
UUID
UUID 是一個(gè)由 128 位組成的唯一標(biāo)識(shí)符,通常以字符串形式表示。它可以通過不同的算法生成,例如基于時(shí)間戳的 UUID(version 1)和基于隨機(jī)數(shù)的 UUID(version 4)等。
UUID 的優(yōu)點(diǎn)
- 全局唯一性:通過不同算法生成,幾乎能夠保證在全球范圍內(nèi)的唯一性,從而避免了多臺(tái)機(jī)器之間可能發(fā)生的主鍵沖突問題。
- 不可預(yù)測(cè)性:隨機(jī)生成的 UUID 很難被猜測(cè),因此在需要保密性的應(yīng)用場(chǎng)景下非常適用。
- 分布式應(yīng)用:由于可以在不同的機(jī)器上生成 UUID,因此可以被廣泛應(yīng)用于分布式系統(tǒng)中。
然而,UUID 作為主鍵 ID 也存在一些缺點(diǎn):
- 存儲(chǔ)空間較大:UUID 通常以字符串形式存儲(chǔ),占用的存儲(chǔ)空間較大。
- 不適合范圍查詢:由于不是自增的,不支持范圍查詢。新生成的 UUID 可能會(huì)插入到已有數(shù)據(jù)的中間位置,導(dǎo)致范圍查詢時(shí)出現(xiàn)數(shù)據(jù)重復(fù)或漏數(shù)據(jù)的情況。
- 不方便展示:UUID 通常比較長(zhǎng),且沒有明確的業(yè)務(wù)含義,因此不太適合在系統(tǒng)間或前臺(tái)頁面進(jìn)行展示。
- 查詢效率低下:
在 UUID 列上創(chuàng)建索引會(huì)導(dǎo)致索引大小增加,從而影響緩存命中率,增加磁盤 I/O 需求,同時(shí)也增加了查詢時(shí)的內(nèi)存開銷。
當(dāng)使用 UUID 進(jìn)行排序時(shí),新生成的 UUID 通常會(huì)插入到葉子節(jié)點(diǎn)的中間位置,導(dǎo)致 B+樹的頻繁分裂和平衡操作,進(jìn)而影響查詢性能。
自增 ID
在 MySQL 中,可以通過設(shè)置 AUTO_INCREMENT 屬性實(shí)現(xiàn) ID 的自增長(zhǎng),通常用于作為主鍵 ID。
使用自增 ID 作為主鍵的好處包括:
- 存儲(chǔ)空間節(jié)?。篒D 為數(shù)字,占用的位數(shù)比 UUID 小得多,因此在存儲(chǔ)空間上更加節(jié)省。
- 查詢效率高:ID 遞增,利于 B+Tree 索引的查詢效率提高。
- 方便展示:ID 較短,方便在系統(tǒng)間或前臺(tái)頁面進(jìn)行展示。
- 分頁方便:ID 連續(xù)自增,有利于解決深度分頁問題。
然而,使用自增主鍵也存在一些問題:
- 分庫分表困難:在分庫分表時(shí),無法依賴單一表的自增主鍵,可能導(dǎo)致沖突問題。
- 可預(yù)測(cè)性:由于 ID 是順序自增的,因此具有一定可預(yù)測(cè)性,存在一定的安全風(fēng)險(xiǎn)。
- 可能用盡:自增 ID 可能是 int、bigint 等,但它們都有范圍限制,可能會(huì)用盡。
- 性能問題:在數(shù)據(jù)遷移期間,如果使用自增主鍵,數(shù)據(jù)庫可能會(huì)產(chǎn)生額外的性能開銷。這可能是由于重新計(jì)算主鍵值或更新相關(guān)索引所致。這可能會(huì)導(dǎo)致數(shù)據(jù)遷移過程變慢。
到底什么是 UUID,它能保證唯一嗎?
UUID(Universally Unique Identifier)是一種全局唯一標(biāo)識(shí)符,用于在同一時(shí)空中的各臺(tái)機(jī)器上保證唯一性。
UUID 的生成基于特定算法,通常使用隨機(jī)數(shù)生成器或基于時(shí)間戳的方式。生成的 UUID 以 32 位 16 進(jìn)制數(shù)表示,總共 128 位(標(biāo)準(zhǔn) UUID 格式為:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,共 32 個(gè)字符)。
由于 UUID 是由 MAC 地址、時(shí)間戳、隨機(jī)數(shù)等信息生成的,因此具有極高的唯一性,幾乎不可能重復(fù)。但在實(shí)際實(shí)現(xiàn)中,UUID 有多種版本,它們的唯一性指標(biāo)也有所不同。
UUID 的具體實(shí)現(xiàn)版本包括基于時(shí)間的 UUID V1 和基于隨機(jī)數(shù)的 UUID V4 等。
在 Java 中,java.util.UUID生成的 UUID 包括 V3 和 V4 兩種版本。
圖片
UUID 的優(yōu)缺點(diǎn)
UUID 的優(yōu)點(diǎn)在于其性能較高,不依賴網(wǎng)絡(luò),可以在本地生成,并且使用起來相對(duì)簡(jiǎn)單。
然而,UUID 也存在兩個(gè)明顯的缺點(diǎn):
- 長(zhǎng)度過長(zhǎng):UUID 通常由 32 位 16 進(jìn)制數(shù)字組成,因此長(zhǎng)度較長(zhǎng)。例如,對(duì)于類似"550e8400-e29b-41d4-a716-446655440000"的字符串,幾乎沒有任何程序員能夠直觀理解其含義。
- 缺乏含義:UUID 是隨機(jī)生成的,因此缺乏任何業(yè)務(wù)或語義上的含義。一旦將其用作全局唯一標(biāo)識(shí),可能導(dǎo)致在日后的問題排查和開發(fā)調(diào)試過程中遇到較大困難。
各個(gè)版本實(shí)現(xiàn)
- V1. 基于時(shí)間戳的 UUID
基于時(shí)間戳的 UUID 是通過計(jì)算當(dāng)前時(shí)間戳、隨機(jī)數(shù)和機(jī)器 MAC 地址得到的。由于算法中使用了 MAC 地址,這個(gè)版本的 UUID 能夠確保在全球范圍內(nèi)的唯一性。然而,使用 MAC 地址也帶來了安全性問題,因此這個(gè)版本的 UUID 受到了批評(píng)。如果應(yīng)用只在局域網(wǎng)中使用,也可以使用一種簡(jiǎn)化的算法,以 IP 地址代替 MAC 地址。
- V2. DCE(Distributed Computing Environment)安全的 UUID
這個(gè)版本的 UUID 算法與基于時(shí)間戳的 UUID 相同,但會(huì)將時(shí)間戳的前 4 位替換為 POSIX 的 UID 或 GID。然而,實(shí)際中較少使用這個(gè)版本的 UUID。
- V3. 基于名稱空間的 UUID(MD5)
基于名稱空間的 UUID 通過計(jì)算名稱和名稱空間的 MD5 散列值得到。這個(gè)版本的 UUID 保證了以下幾點(diǎn):在相同名稱空間中,不同名稱生成的 UUID 具有唯一性;不同名稱空間中的 UUID 是唯一的;在相同名稱空間中,相同名稱生成的 UUID 是重復(fù)的。
- V4. 基于隨機(jī)數(shù)的 UUID
基于隨機(jī)數(shù)的 UUID 是根據(jù)隨機(jī)數(shù)或偽隨機(jī)數(shù)生成的。該版本的 UUID 使用隨機(jī)數(shù)生成器生成,保證了生成的 UUID 具有極佳的唯一性。然而,由于其基于隨機(jī)數(shù),因此不太適用于數(shù)據(jù)量特別大的場(chǎng)景。
- V5. 基于名稱空間的 UUID(SHA1)
與版本 3 的 UUID 算法相似,但使用 SHA1(Secure Hash Algorithm 1)算法進(jìn)行散列值計(jì)算。
各版本 UUID 簡(jiǎn)要總結(jié)如下:
Version 1 和 Version 2:
- 基于時(shí)間戳和 MAC 地址,適合分布式計(jì)算環(huán)境,具有高度唯一性。
Version 3 和 Version 5:
- 基于名稱空間,在一定范圍內(nèi)是唯一的,可用于生成重復(fù) UUID 的場(chǎng)景。
Version 4:
- 簡(jiǎn)單地基于隨機(jī)數(shù)生成,適合數(shù)據(jù)量不是特別大的場(chǎng)景,但可靠性較低。