uuid演算法

㈠ 什麼是UUID，Java中怎麼產生UUID

UUID 是 通用唯一識別碼（Universally Unique Identifier）的縮寫，是一種軟體建構的標准，亦為開放軟體基金會組織在分布式計算環境領域的一部分。其目的，是讓分布式系統中的所有元素，都能有唯一的辨識信息，而不需要通過中央控制端來做辨識信息的指定。

生成UUID的方法：

public static String getUUID32(){ String uuid = UUID.randomUUID().toString().replace("-", "").toLowerCase(); return uuid;// return UUID.randomUUID().toString().replace("-", "").toLowerCase();}

註：因為一般資料庫主鍵為String類型，所以接收類型為String，生成的uuid數據包含-，所以要去掉-，故UUID.randomUUID().toString().replace("-", "").toLowerCase()。

(1)uuid演算法擴展閱讀：

UUID由以下幾部分的組合：

（1）當前日期和時間，UUID的第一個部分與時間有關，如果你在生成一個UUID之後，過幾秒又生成一個UUID，則第一個部分不同，其餘相同。

（2）時鍾序列。

（3）全局唯一的IEEE機器識別號，如果有網卡，從網卡MAC地址獲得，沒有網卡以其他方式獲得。

UUID的唯一缺陷在於生成的結果串會比較長。關於UUID這個標准使用最普遍的是微軟的GUID(Globals Unique Identifiers)。在ColdFusion中可以用CreateUUID()函數很簡單地生成UUID，其格式為：xxxxxxxx-xxxx- xxxx-xxxxxxxxxxxxxxxx(8-4-4-16)。

其中每個 x 是 0-9 或 a-f 范圍內的一個十六進制的數字。而標準的UUID格式為：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12)，可以從cflib 下載CreateGUID() UDF進行轉換。

㈡ GUID什麼意思

GUID(Globally Unique IDentifier) 也稱作 UUID(Universally Unique IDentifier).

特點：

GUID/UUID是通過特定演算法產生的一個二進制長度為128位的數字，

在空間上和時間上具有唯一性，保證同一時間不同地方產生的數字不同，

在公元3400年以前產生的UUID/GUID與任何其他產生過的UUIDs/GUIDs都不相同。

在需要GUID的時候，可以完全由演算法自動生成，不需要一個權威機構來管理。

GUID的長度固定，並且相對而言較短小，非常適合於排序、標識和存儲。

用途：

標識特定的組件、程序、文件、數據、用戶等，並可以在網路中使用。

格式：
UUID 字元串格式可以由下面的EBNF語言來描述:

UUID = <time_low> "-" <time_mid> "-"
<time_high_and_version> "-"
<clock_seq_and_reserved>
<clock_seq_low> "-" <node>
time_low = 4*<hexOctet>
time_mid = 2*<hexOctet>
time_high_and_version = 2*<hexOctet>
clock_seq_and_reserved = <hexOctet>
clock_seq_low = <hexOctet>
node = 6*<hexOctet>
hexOctet = <hexDigit> <hexDigit>
hexDigit =
"0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
| "a" | "b" | "c" | "d" | "e" | "f"
| "A" | "B" | "C" | "D" | "E" | "F"

例如：f81d4fae-7dec-11d0-a765-00a0c91e6bf6

演算法：

GUID的演算法並不唯一，可以由多種方法來生成。

GUID生成器除了標識不同的時間，還要唯一地標識不同的地點，這可以使用網卡的48位的IEEE 802地址。

GUID的128位可以分為16個位元組，前8個位元組是時間和版本號，中間2個位元組是UUID變體和時鍾序數，後6個位元組標識地點。

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_mid | time_hi_and_version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|clk_seq_hi_res | clk_seq_low | node (0-1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| node (2-5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

UUID變體位於第9個位元組的前3位，有4種定義：

Msb0 Msb1 Msb2 Description

0 - - Reserved, NCS backward compatibility.

1 0 - The variant specified in this document.

1 1 0 Reserved, Microsoft Corporation backward
compatibility

1 1 1 Reserved for future definition.

版本號位於第7個位元組的前4位：

Msb0 Msb1 Msb2 Msb3 Version Description

0 0 0 1 1 The time-based version
specified in this
document.

0 0 1 0 2 Reserved for DCE
Security version, with
embedded POSIX UIDs.

0 0 1 1 3 The name-based version
specified in this
document

0 1 0 0 4 The randomly or pseudo-
randomly generated
version specified in
this document

時間的標識(Timestamp)

UUID version 1, UTC時間從 00:00:00.00, 15 October 1582開始以100納秒的計數.
沒有UTC時間時，也可以使用當地時間，只要在系統中保持一貫就行，這並不推薦，
當地時間與UTC時間只是一個時差的問題。
UTC - Coordinated Universal Time

UUID version 3, 由名字空間產生一個60位數.

UUID version 4, 隨機地或偽隨機地產生一個60位數.

時鍾序數 Clock sequence

UUID version 1, 時鍾序數用來避免鍾表被調慢後產生重復。比如網卡移到別的機器上，或者斷電等。
如果先前的時鍾序數已知，加1即可，否則隨機產生，更換隨機數種子以減小重復的可能性。

UUID version 3, 由名字空間產生一個14位數.

地點的標識(node)

UUID version 1, 採用主機的IEEE 地址,系統有多個IEEE 802地址時，任取一個；

沒有IEEE地址時,使隨機數或偽隨機數並保證與網卡上地址不同(見 section 4).

UUID version 3, 由名字空間產生一個48位數.

UUID version 4, 隨機地或偽隨機地產生一個48位數.

參考文獻：
http://www.ics.uci.e/~ejw/authoring/uuid-guid/draft-leach-uuids-guids-01.txt

㈢ hibernate中，定義主鍵id的 generator的class="uuid" 那麼這個Id是不是自動增加

首先要知道它的生成原理：
UUID演算法使用IP地址、JVM的啟動時間、系統時間和一個計數值來產生主鍵。
同時包括兩種方式實現：
uuid.hex由Hibernate基於128
位唯一值產生演算法生成16
進制數值（編碼後以長度32
的字元串表示）作為主鍵。
uuid.string與uuid.hex
類似，只是生成的主鍵未進行編碼（長度16）。在某些資料庫中可能出現問題（如Postgresql）。
所以呢。。。它每次生成的值不相同的。。。而且生成的結果是字元串形式的。。。故不是自動增長的。。。
自動增長用於數值類型的資料庫作為主鍵的形式。

㈣ js中如何產生uuid

http://www.broofa.com/Tools/Math.uuid.js

Math.uuid = (function() {

// Private array of chars to use

var CHARS = ''.split('');

return function (len, radix) {

var chars = CHARS, uuid = [], rnd = Math.random;

radix = radix || chars.length;

if (len) {

// Compact form

for (var i = 0; i < len; i++) uuid[i] = chars[0 | rnd()*radix];

} else {

// rfc4122, version 4 form

var r;

// rfc4122 requires these characters

uuid[8] = uuid[13] = uuid[18] = uuid[23] = '-';

uuid[14] = '4';

// Fill in random data. At i==19 set the high bits of clock sequence as

// per rfc4122, sec. 4.1.5

for (var i = 0; i < 36; i++) {

if (!uuid[i]) {

r = 0 | rnd()*16;

uuid[i] = chars[(i == 19) ? (r & 0x3) | 0x8 : r & 0xf];

}

}

}

return uuid.join('');

};

})();

// Deprecated - only here for backward compatability

var randomUUID = Math.uuid;

function generateUUID()

{

return Math.uuid();

}

㈤ 關於UDID和UUID的區別

UDID和UUID的區別如下：

一、定義的不同：

所謂UDID指的是設備的唯一設備識別符，移動廣告商和游戲網路運營商往往需要通過UDID用來識別玩家用戶，並對用戶活動進行跟蹤。。而UUID 是通用唯一識別碼，是一種軟體建構的標准，亦為開放軟體基金會組織在分布式計算環境領域的一部分。其目的，是讓分布式系統中的所有元素，都能有唯一的辨識信息，而不需要通過中央控制端來做辨識信息的指定。

二、用途不同：

UDID用於一些統計與分析目的、將UDID作為用戶ID來唯一識別用戶，省去用戶名，密碼等注冊過程。而UUID 的目的是讓分布式系統中的所有元素，都能有唯一的辨識資訊，而不需要透過中央控制端來做辨識資訊的指定。如此一來，每個人都可以建立不與其它人沖突的 UUID。在這樣的情況下，就不需考慮資料庫建立時的名稱重復問題。

(5)uuid演算法擴展閱讀：

基於時間的UUID通過計算當前時間戳、隨機數和機器MAC地址得到。由於在演算法中使用了MAC地址，這個版本的UUID可以保證在全球范圍的唯一性。但與此同時，使用MAC地址會帶來安全性問題，這就是這個版本UUID受到批評的地方。如果應用只是在區域網中使用，也可以使用退化的演算法，以IP地址來代替MAC地址－－Java的UUID往往是這樣實現的。

通用唯一標識符還可以用來指向大多數的可能的物體。微軟和其他一些軟體公司都傾向使用全球唯一標識符（GUID），這也是通用唯一標識符的一種類型，可用來指向組建對象模塊對象和其他的軟體組件。第一個通用唯一標識符是在網路計算機系統（NCS）中創建，並且隨後成為開放軟體基金會（OSF）的分布式計算環境（DCE）的組件。

㈥ mysql裡面什麼是uuid

首先,在mysql里建議不要用非自增id做主鍵,不然插入速度很慢,除非是查詢為主的表。uuid主要解決的是分布式生成唯一編號的問題,不一定非要用現有的uuid方法

㈦ PostgreSQL中使用UUID

UUID（Universal Unique Identifier）或者 GUID（Globally Unique Identifier）是一個 128 比特的數字，可以用於唯一標識每個網路對象或資源。由於它的生成機制，一個 UUID 可以保證幾乎不會與其他 UUID 重復，因此常常用於生成資料庫中的主鍵值。

1.pgcrypto 模塊提供的 uuid

PostgreSQL 提供了一個用於加/解密的擴展模塊 pgcrypto，其中的 gen_random_uuid() 函數可以用於返回一個 version 4 的隨機 UUID。

2.uuid-ossp 模塊提供的 uuid

uuid-ossp模塊提供函數使用幾種標准演算法之一產生通用唯一標識符（UUID）。還提供產生某些特殊 UUID 常量的函數。

1.將當前目錄轉移到 PostgreSQL 源代碼目錄下的 contrib；如：

2.執行如下命令來安裝擴展模塊

如果要安裝 uuid-ossp 模塊，需要在執行安裝擴展模塊之前，執行 configure 並添加 --with-uuid=xxx，xxx取值為：

然後再執行安裝擴展模塊的命令。

3.檢查是否安裝，在 PostgreSQL 的安裝目錄下的 /share/extension 目錄下，查看是否有模塊相關的文件。如：

註： gen_random_uuid() 從 PostgreSQL 13 開始成為了一個內置函數

如果您所使用的PostgreSQL版本在13以上，則不需要執行如下語句：

生成uuid：

如果想要生成沒有中劃線（-）的 UUID 字元串，可以使用 REPLACE 函數：

查看包含的函數：

執行如下命令生成 uuid：

㈧ 如何選擇主鍵uuid

以前對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條數據測試一下看看來著，可惜一測試，硬碟燈就一直亮，讓我很擔心它會掛，雖然硬碟不值錢，但是我重要的數據都在上面，一旦壞了，損失就大了，所以，測試只好作罷。