1. UUID 是什么？
UUID（Universally Unique Identifier 通用唯一識別碼）用于標(biāo)識資源唯一性。理論上說，門牌號、電話號碼、郵編、身份證號都是用來標(biāo)識資源唯一性的，但為使用方便，不適合用一個無規(guī)律的字符串表示，UUID 主要還是在程序中使用。
UUID 源自1980年代的 Apollo 電腦公司，是一個 128 位的標(biāo)識符，理論上的總數(shù)有 2128個，也就是說，哪怕每納秒產(chǎn)生 1 萬億個 UUID，也要 100 億年才能用完。因此，只要保證生成方法的散布足夠好，統(tǒng)計概率上，UUID 重復(fù)的可能性約等于 0 。
UUID 的具體規(guī)范可以參考 RFC 4122。這個標(biāo)準(zhǔn)定義了 5 個版本的 UUID：
- 版本 1 根據(jù)時間和 mac 地址來生成 UUID。MAC 地址用于保證設(shè)備唯一性。通過在時間戳后加入 13-14 位的時鐘序列，可以保證在同一臺設(shè)備，同 1 秒內(nèi)生成的 1630 億個 UUID 不重復(fù)。 這個版本的 UUID 我們用得相對較少，一個原因是其中攜帶了設(shè)備信息。1999 年，著名病毒梅麗莎的作者，因為代碼中的 UUID 暴露了 MAC 地址信息，不到一個星期就被抓住了。另一個原因是這個版本的 UUID 生成有規(guī)律，比較容易根據(jù)一個 UUID 推斷到下一個 UUID。
- 版本 2 是一個 DEC 安全的版本，RFC4122 中也沒有詳細(xì)說明具體實現(xiàn)方式，我們一般也用不到。
- 版本 3 根據(jù)字符串和命名空間散列值（HASH）來獲取 UUID。由于 HASH 函數(shù)本身的特性，一般不用擔(dān)心 UUID 沖突，或者別人根據(jù)散列值反推原數(shù)據(jù)的問題。這個版本采用的是 MD5 散列值。
- 版本 4 根據(jù)隨機數(shù)生成 UUID，是我們比較常用的版本。
- 版本 5 和版本 3 一樣，也是根據(jù)散列值獲取 UUID，不過采用的散列算法是 SHA-1 而不是 MD5，相較而言，RFC4122 推薦大家使用版本 5 而不是版本 3。
我們常看到的 UUID 往往被表示為 16 進(jìn)制數(shù)字和橫杠組成的字符串，比如：a3535b78-69dd-4a9e-9a79-57e2ea28981b，其中第二個橫杠之后的第一個數(shù)字表示 UUID 版本，例子中這個 UUID 就是版本 4 的。
2. 為什么在數(shù)據(jù)庫中使用 UUID？
大多數(shù)人在數(shù)據(jù)庫中存儲 UUID 的直接原因，是需要一個不暴露內(nèi)部信息的唯一標(biāo)識。例如博客文章，Title 無法保證不重復(fù)，數(shù)字 ID 則會暴露內(nèi)部信息，于是，可以生成一個 UUID 作為唯一標(biāo)識。類似地，我們在網(wǎng)上請求的許多公開資源，如圖片、音頻、以及其他文件等，都是以 UUID 作為標(biāo)識的。
第二個原因，是為了方便數(shù)據(jù)管理：
- 當(dāng)數(shù)據(jù)量過大，不得不進(jìn)行分片管理的時候，數(shù)字 ID 的唯一性不好保證；萬一需要重建部分?jǐn)?shù)據(jù)，數(shù)字 ID 也很難確保與原表一致。
- UUID 作為預(yù)先生成的值，可以在插入數(shù)據(jù)庫之前拿到，會方便一些數(shù)據(jù)操作。
3. UUID 作為主鍵有什么問題？
一般不推薦把 UUID 作為主鍵，它會帶來不少問題：
3.1 數(shù)據(jù)碎片化
我們知道，使用自增 ID 作為主鍵時，插入新的數(shù)據(jù)行往往是連續(xù)的，插入多條數(shù)據(jù)只需要讀寫少數(shù)數(shù)據(jù)頁。但由于 UUID 的隨機性，新插入的數(shù)據(jù)往往會落在不同的數(shù)據(jù)頁上，導(dǎo)致數(shù)據(jù)碎片化，同樣的數(shù)據(jù)量，可能需要更大的空間才能存儲。
同時，當(dāng)數(shù)據(jù)量上升，內(nèi)存中無法暫存足夠多的數(shù)據(jù)頁時，每次插入數(shù)據(jù)都可能涉及硬盤讀寫，極大地拖慢了數(shù)據(jù)插入效率。
3.2 索引占用空間過大
大多數(shù)人會把 UUID 保存為 16 進(jìn)制數(shù)字和橫杠組成的字符串，也就是 char(36)，如果采用 UTF-8 字符集，它所占的字節(jié)數(shù)是 2 + 3 * 36 = 110 字節(jié)（前面 2 個字節(jié)為長度，后面每個字符 3 個字節(jié)）。相較而言，一個整數(shù)只有 4 個字節(jié)，相差 27 倍。
數(shù)據(jù)庫采用 B 樹索引，其中主鍵索引的葉子節(jié)點指向數(shù)據(jù)行，而二級索引的葉子節(jié)點存儲著主鍵，之后再通過主鍵索引回表查數(shù)據(jù)。也就是說，有多少個二級索引，主鍵就需要被存儲幾次，因此，索引的空間需求就極速擴張了。
在數(shù)據(jù)庫運行過程中，為加快查詢速度，這些索引往往需要被加載到內(nèi)存中。那么，過大的索引導(dǎo)致內(nèi)存不足，就會嚴(yán)重影響數(shù)據(jù)庫查詢效率。
3.3 字符比較比整數(shù)比較慢
CPU 每次最多可以比較 8 個字節(jié)的整數(shù)值，但對于字符串，必須一個字符一個字符比較過去。有測試說明，在查詢比較時，使用整數(shù)的速度比使用字符串的速度快數(shù)倍到數(shù)十倍之間。
不過，一般來說，數(shù)據(jù)庫不是一個 CPU 密集的應(yīng)用，因此這方面的影響不是主要考慮因素。
4. 替代方案討論
4.1 優(yōu)化 UUID 的存儲
將 UUID 存儲為 16 進(jìn)制值和橫杠組成的字符串是非常低效的，UUID 本身只有 128 位，也就是 16 字節(jié)，存儲成字符串后卻有 110 個字節(jié)，膨脹了 7 倍，憑空多占了不少空間。優(yōu)化的思路就是采用更好的格式，比如直接存儲二進(jìn)制，或者將二進(jìn)制值存儲為 base64 字符串。相對復(fù)雜一點的是將 UUID 映射到一個整數(shù)。
優(yōu)化存儲格式的具體實現(xiàn)都不困難，也能相當(dāng)程度地節(jié)約存儲空間，但并沒有解決 UUID 的隨機性帶來的數(shù)據(jù)碎片化的問題。
針對碎片化的問題，有一個思路是控制隨機性，也就是增加一個自己生成的字符串作為前綴，比如說日期（或它的哈希值）。因為字符串排序從前往后走，同樣的前綴也就意味著接近的排序，那么，原本散布在整個數(shù)據(jù)庫的值，就會集中分布在一定范圍內(nèi)的數(shù)據(jù)頁，從而大大緩解了內(nèi)存壓力。
4.2 同時使用自增 ID 和 UUID
更常見的思路，是使用自增 ID 作為主鍵，同時使用 UUID 作為唯一標(biāo)識和與其它表關(guān)聯(lián)的外鍵。好處是有了一個可以比較安全地對外暴露的唯一標(biāo)識，節(jié)約了索引空間，也不用擔(dān)心數(shù)據(jù)分片和數(shù)據(jù)重建帶來的危險。
但也存在一些問題，因為所有的外鍵關(guān)聯(lián)都用的 UUID，所以占用的空間自然會大一些，同時，字符串比較速度較慢和所有查詢都要回表也是值得考慮的因素。
4.3 避開 UUID
很多小型應(yīng)用不需要考慮數(shù)據(jù)管理的問題，只是需要一個可以對外暴露的唯一標(biāo)識，于是，干脆放棄 UUID，采用其他思路實現(xiàn)標(biāo)識的唯一性。
比如說前面說的博客文章，鑒于 Title 沒法保證唯一性，可以在 Title 前后加上一個前綴或者后綴，從而實現(xiàn)唯一性。一個思路是使用隨機字符串，或者作者、日期等信息。
又比如說，將每個數(shù)據(jù)行映射到一個大整數(shù)作為唯一標(biāo)識。某種意義上等于根據(jù)自己的實際需要寫了一套新的唯一標(biāo)識算法。
END
