(轉)UUID做主鍵,好還是不好?這是個問題。

2022-10-10 13:54:14 字數 2388 閱讀 9617

以前對uuid的了解很少,只知道是128位整數(16位元組)的全域性唯一識別符號(universally unique identifier)。

剛才google了下,算是有了點深入的了解。

uuid是指在一台機器上生成的數字,它保證對在同一時空中的所有機器都是唯一的。通常平台會提供生成uuid的api。uuid按照開放軟體**會(osf)制定的標準計算,用到了乙太網卡位址、納秒級時間、晶元id碼和許多可能的數字。由以下幾部分的組合:當前日期和時間(uuid的第乙個部分與時間有關,如果你在生成乙個uuid之後,過幾秒又生成乙個uuid,則第乙個部分不同,其餘相同),時鐘序列,全域性唯一的ieee機器識別號(如果有網絡卡,從網絡卡獲得,沒有網絡卡以其他方式獲得),uuid的唯一缺陷在於生成的結果串會比較長。關於uuid這個標準使用最普遍的是微軟的guid(globals unique identifiers)。

使用uuid的好處在分布式的軟體系統中(比如:dce/rpc, com+,corba)就能體現出來,它能保證每個節點所生成的標識都不會重複,並且隨著web服務等整合技術的發展,uuid的優勢將更加明顯。

我唯一還算熟悉的資料庫就算是mysql了,大概使用mysql的人,百分之九九以上的人會使用autoincrement id做主鍵,這是可以理解的,因為mysql的自增id效率很高,使用也很方便。那麼剩下的百分之一的人使用什麼做主鍵呢?可能是自己做的keygenerator,也可能是我們下面要說的uuid。

據說在oracle的圈子裡,如果誰用自增id做主鍵是要被鄙視的,主鍵最自然的選擇就是uuid。我不了解oracle,這些道聽途說的結論是否正確不做承諾。

那麼我們先看看什麼是uuid?簡單的說,uuid是指在一台機器上生成的數字,它保證對在同一時空中的所有機器都是唯一的。在uuid的演算法中,可能會用到諸如網絡卡mac位址,ip,主機名,程序id等資訊以保證其獨立性。

如果你的mysql版本不太老的話,鍵入 select uuid(); 輸出的就是uuid,如下:

mysql> select uuid();

+--------------------------------------+

| uuid() |

+--------------------------------------+

| 54b4c01f-dce0-102a-a4e0-462c07a00c5e |

+--------------------------------------+

現在大家應該對uuid有乙個比較直觀的認識了,我們來看看uuid的優缺點分別是什麼。

優點:能夠保證獨立性,程式可以在不同的資料庫間遷移,效果不受影響。

保證生成的id不僅是表獨立的,而且是庫獨立的,這點在你想切分資料庫的時候尤為重要。

缺點:比較佔地方,和int型別相比,儲存乙個uuid要花費更多的空間。

使用uuid後,url顯得冗長,不夠友好。

下面針對上述uuid的缺點說說我的看法,比較佔地方這個缺點我不是很在乎,現在最不值錢的就是硬碟了,略過此條缺點無妨,但需要注意的一點資料在索引的時候效率會隨著體積的增加而降低。至於說使用uuid後,url顯得不友好,我覺得這多少是你的int情結造成的慣性思維,其實,和int型別相比,uuid才是最自然的主鍵選擇,注意,我這裡用的是自然這個形容詞,仔細體會一下你能理解我的意思。另外,很多時候,url本身就不需要友好,比如,乙個電子商務**,按照int友好的url說法,她的訂單url大概是下面這個形式的:/order.php/id/123,我要說明的是,這樣是很友好,但是有些太友好了,友好的甚至不安全,比如說,我早晨下乙個訂單,發現url是/order.php/id/1000,晚上再下乙個訂單發現url是/order.php/id/2000,那麼我就可以估計出此**一天的訂單數大致是1000左右,甚至能大體估計出它的銷售額,而這些資料往往都是重要的商業秘密。使用uuid就沒有這個顧慮。

效率?如果上面說的uuid的所謂缺點都不成立的話,那麼是否使用uuid做主鍵,唯一的問題就是效率了。據說在postgresql等資料庫裡,都有專門的uuid型別,在這樣的資料庫裡,使用uuid做主鍵,效率沒有任何問題,可惜在mysql裡沒有這樣的字段,如果想在mysql裡儲存uuid做主鍵,一般是使用char(36)來模擬,因為不是乙個原生的uuid型別,所以主鍵的效率到底如何有待測試,另外,uuid做主鍵的效率和uuid本身的演算法實現也有很大關係。

另外,對於innodb這種聚集主鍵型別的引擎來說,資料會按照主鍵進行排序,由於uuid的無序性,innodb會產生巨大的io壓力,此時不適合使用uuid做物理主鍵,可以把它作為邏輯主鍵,物理主鍵依然使用自增id。

我本來想在我自己的電腦上插入1000000條資料測試一下看看來著,可惜一測試,硬碟燈就一直亮,讓我很擔心它會掛,雖然硬碟不值錢,但是我重要的資料都在上面,一旦壞了,損失就大了,所以,測試只好作罷。

至於在mysql上使用uuid(用char(36)儲存,也可以用binary(16)儲存)做主鍵,效率到底如何,我也不知道,抱歉 -_-!!!

為什麼是UUID做主鍵

ing 專業要飯 22 43 32 現在好多專案資料庫的表id都是用uuid哦,這是為什麼?ing 專業要飯 22 43 37 ashier.htm?orderid 879b2c046adf664e40bd6b7b7e1f6d6f ing 專業要飯 22 43 46 這是支付寶的。境由心造 22 4...

DateTime做主鍵 三

總結 關鍵點在於 datetime 資料型別轉化 補充資料 datetimeformatinfo 類 dotnet類庫 下表列出了每一種標準模式的標準格式字元以及可以進行設定以修改標準模式的關聯datetimeformatinfo屬性。格式字元區分大小寫 例如,g 和 g 所代表的模式稍有不同。格式...

使用Guid做主鍵和int做主鍵效能比較

摘自 1.在經常需要做資料遷移的系統中,建議用guid。並且在相應的外來鍵字段,也就是用來做連線查詢的字段新增非聚集索引,對於改善效能有極大的好處。where條件的字段也可以適當新增非聚集索引。2.在使用guid型別作為主鍵時,資料型別應為uniqueidentifier,並且一定要記得取消主鍵的 ...