在數(shù)據(jù)庫中唯一標(biāo)識行的最常見方法之一是使用UUID字段。然而，這種方法帶來了需要注意的性能問題。

本文將討論在使用UUID作為數(shù)據(jù)庫表中的鍵時可能出現(xiàn)的兩個性能問題。

我們直接進(jìn)入正題！

什么是UUID？

UUID代表通用唯一標(biāo)識符（Universally Unique Identifier）。UUID有很多版本，但在本文中，我們將討論最流行的版本：UUIDv4。

以下是UUIDv4的一個示例：

問題1 —— 插入性能

當(dāng)向表中插入新記錄時，必須更新與主鍵相關(guān)的索引以保持最佳查詢性能。索引是使用B+樹數(shù)據(jù)結(jié)構(gòu)構(gòu)建的。

對于UUIDv4來說，重新平衡過程變得非常低效。這是因?yàn)閁UID的固有隨機(jī)性，使得保持樹的平衡變得更加困難。當(dāng)你的數(shù)據(jù)規(guī)模擴(kuò)大時，需要重新平衡數(shù)百萬個節(jié)點(diǎn)，這顯著降低了使用UUID鍵的插入性能。

問題2 —— 更高的存儲需求

我們考慮一個帶有自動遞增整數(shù)鍵的UUID的大小：

自動遞增整數(shù)每個值消耗32位，而UUID每個值消耗128位。

每行UUID的存儲空間是整數(shù)的4倍。

此外，大多數(shù)人以人類可讀的形式存儲UUID，這意味著UUID每個值可能消耗多達(dá)688位。這是整數(shù)的約20倍。

讓我們通過模擬一個現(xiàn)實(shí)的數(shù)據(jù)庫來評估UUID如何實(shí)際影響存儲。

我們將使用Josh Tried Coding的示例表：

這個示例使用了Neon PostgreSQL數(shù)據(jù)庫。

• 表1將包含100萬行UUID。
• 表2將包含100萬行自動遞增整數(shù)。

以下是結(jié)果，讓我們逐一分析每個統(tǒng)計數(shù)據(jù)：

圖片

總表大小：考慮到兩個表的大小，UUID表大約是整數(shù)表的2.3倍！

ID字段大小：單個UUID字段需要比等效整數(shù)字段多9.3倍的存儲空間！

ID列大小：排除每個表中的其他屬性時，UUID和整數(shù)列之間的大小差異為3.5倍！

結(jié)論

UUID是確保表中記錄唯一性的好方法。然而，這些問題在大規(guī)模使用時尤為明顯，因此對于大多數(shù)人來說，UUID實(shí)際上不會導(dǎo)致明顯的性能下降。

盡管這些問題在大規(guī)模使用時普遍存在，但重要的是要了解在表中使用UUID的影響，并確保數(shù)據(jù)庫設(shè)計的優(yōu)化。