之前無意間看到群友討論到用什么做主鍵比較好

圖片

圖片

圖片

其實 UUID 和自增主鍵 ID 是常用于數(shù)據(jù)庫主鍵的兩種方式，各自具有獨特的優(yōu)缺點。

UUID

UUID 是一個由 128 位組成的唯一標(biāo)識符，通常以字符串形式表示。它可以通過不同的算法生成，例如基于時間戳的 UUID（version 1）和基于隨機(jī)數(shù)的 UUID（version 4）等。

UUID 的優(yōu)點

• 全局唯一性：通過不同算法生成，幾乎能夠保證在全球范圍內(nèi)的唯一性，從而避免了多臺機(jī)器之間可能發(fā)生的主鍵沖突問題。
• 不可預(yù)測性：隨機(jī)生成的 UUID 很難被猜測，因此在需要保密性的應(yīng)用場景下非常適用。
• 分布式應(yīng)用：由于可以在不同的機(jī)器上生成 UUID，因此可以被廣泛應(yīng)用于分布式系統(tǒng)中。

然而，UUID 作為主鍵 ID 也存在一些缺點：

• 存儲空間較大：UUID 通常以字符串形式存儲，占用的存儲空間較大。
• 不適合范圍查詢：由于不是自增的，不支持范圍查詢。新生成的 UUID 可能會插入到已有數(shù)據(jù)的中間位置，導(dǎo)致范圍查詢時出現(xiàn)數(shù)據(jù)重復(fù)或漏數(shù)據(jù)的情況。
• 不方便展示：UUID 通常比較長，且沒有明確的業(yè)務(wù)含義，因此不太適合在系統(tǒng)間或前臺頁面進(jìn)行展示。
• 查詢效率低下：

在 UUID 列上創(chuàng)建索引會導(dǎo)致索引大小增加，從而影響緩存命中率，增加磁盤 I/O 需求，同時也增加了查詢時的內(nèi)存開銷。

當(dāng)使用 UUID 進(jìn)行排序時，新生成的 UUID 通常會插入到葉子節(jié)點的中間位置，導(dǎo)致 B+樹的頻繁分裂和平衡操作，進(jìn)而影響查詢性能。

自增 ID

在 MySQL 中，可以通過設(shè)置 AUTO_INCREMENT 屬性實現(xiàn) ID 的自增長，通常用于作為主鍵 ID。

使用自增 ID 作為主鍵的好處包括：

• 存儲空間節(jié)?。篒D 為數(shù)字，占用的位數(shù)比 UUID 小得多，因此在存儲空間上更加節(jié)省。
• 查詢效率高：ID 遞增，利于 B+Tree 索引的查詢效率提高。
• 方便展示：ID 較短，方便在系統(tǒng)間或前臺頁面進(jìn)行展示。
• 分頁方便：ID 連續(xù)自增，有利于解決深度分頁問題。

然而，使用自增主鍵也存在一些問題：

• 分庫分表困難：在分庫分表時，無法依賴單一表的自增主鍵，可能導(dǎo)致沖突問題。
• 可預(yù)測性：由于 ID 是順序自增的，因此具有一定可預(yù)測性，存在一定的安全風(fēng)險。
• 可能用盡：自增 ID 可能是 int、bigint 等，但它們都有范圍限制，可能會用盡。
• 性能問題：在數(shù)據(jù)遷移期間，如果使用自增主鍵，數(shù)據(jù)庫可能會產(chǎn)生額外的性能開銷。這可能是由于重新計算主鍵值或更新相關(guān)索引所致。這可能會導(dǎo)致數(shù)據(jù)遷移過程變慢。

到底什么是 UUID，它能保證唯一嗎？

UUID（Universally Unique Identifier）是一種全局唯一標(biāo)識符，用于在同一時空中的各臺機(jī)器上保證唯一性。

UUID 的生成基于特定算法，通常使用隨機(jī)數(shù)生成器或基于時間戳的方式。生成的 UUID 以 32 位 16 進(jìn)制數(shù)表示，總共 128 位（標(biāo)準(zhǔn) UUID 格式為：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx，共 32 個字符）。

由于 UUID 是由 MAC 地址、時間戳、隨機(jī)數(shù)等信息生成的，因此具有極高的唯一性，幾乎不可能重復(fù)。但在實際實現(xiàn)中，UUID 有多種版本，它們的唯一性指標(biāo)也有所不同。

UUID 的具體實現(xiàn)版本包括基于時間的 UUID V1 和基于隨機(jī)數(shù)的 UUID V4 等。

在 Java 中，java.util.UUID生成的 UUID 包括 V3 和 V4 兩種版本。

圖片

UUID 的優(yōu)缺點

UUID 的優(yōu)點在于其性能較高，不依賴網(wǎng)絡(luò)，可以在本地生成，并且使用起來相對簡單。

然而，UUID 也存在兩個明顯的缺點：

1. 長度過長：UUID 通常由 32 位 16 進(jìn)制數(shù)字組成，因此長度較長。例如，對于類似"550e8400-e29b-41d4-a716-446655440000"的字符串，幾乎沒有任何程序員能夠直觀理解其含義。
2. 缺乏含義：UUID 是隨機(jī)生成的，因此缺乏任何業(yè)務(wù)或語義上的含義。一旦將其用作全局唯一標(biāo)識，可能導(dǎo)致在日后的問題排查和開發(fā)調(diào)試過程中遇到較大困難。

各個版本實現(xiàn)

• V1. 基于時間戳的 UUID

基于時間戳的 UUID 是通過計算當(dāng)前時間戳、隨機(jī)數(shù)和機(jī)器 MAC 地址得到的。由于算法中使用了 MAC 地址，這個版本的 UUID 能夠確保在全球范圍內(nèi)的唯一性。然而，使用 MAC 地址也帶來了安全性問題，因此這個版本的 UUID 受到了批評。如果應(yīng)用只在局域網(wǎng)中使用，也可以使用一種簡化的算法，以 IP 地址代替 MAC 地址。

• V2. DCE(Distributed Computing Environment)安全的 UUID

這個版本的 UUID 算法與基于時間戳的 UUID 相同，但會將時間戳的前 4 位替換為 POSIX 的 UID 或 GID。然而，實際中較少使用這個版本的 UUID。

• V3. 基于名稱空間的 UUID(MD5)

基于名稱空間的 UUID 通過計算名稱和名稱空間的 MD5 散列值得到。這個版本的 UUID 保證了以下幾點：在相同名稱空間中，不同名稱生成的 UUID 具有唯一性；不同名稱空間中的 UUID 是唯一的；在相同名稱空間中，相同名稱生成的 UUID 是重復(fù)的。

• V4. 基于隨機(jī)數(shù)的 UUID

基于隨機(jī)數(shù)的 UUID 是根據(jù)隨機(jī)數(shù)或偽隨機(jī)數(shù)生成的。該版本的 UUID 使用隨機(jī)數(shù)生成器生成，保證了生成的 UUID 具有極佳的唯一性。然而，由于其基于隨機(jī)數(shù)，因此不太適用于數(shù)據(jù)量特別大的場景。

• V5. 基于名稱空間的 UUID(SHA1)

與版本 3 的 UUID 算法相似，但使用 SHA1（Secure Hash Algorithm 1）算法進(jìn)行散列值計算。

各版本 UUID 簡要總結(jié)如下：

Version 1 和 Version 2：

• 基于時間戳和 MAC 地址，適合分布式計算環(huán)境，具有高度唯一性。

Version 3 和 Version 5：

• 基于名稱空間，在一定范圍內(nèi)是唯一的，可用于生成重復(fù) UUID 的場景。

Version 4：

• 簡單地基于隨機(jī)數(shù)生成，適合數(shù)據(jù)量不是特別大的場景，但可靠性較低。