我在網(wǎng)上找了好久，有的人說uuid比較好，就是在分庫分表，合并數(shù)據(jù)什么的比較容易，也有的人說自增好，到了表的數(shù)據(jù)多的時候，性能比uuid好得多，到底那種比較好呢？有沒有在真實生產(chǎn)環(huán)境的大神，來給出一個完整的解答？
11 回答
繁花不似錦
TA貢獻1851條經(jīng)驗 獲得超4個贊
首先UUID的性能并不比自增ID差很多，這取決于UUID的生成算法。舉個例子MongoDB所采用的ObjectId就是一個比較優(yōu)秀的UUID策略，其組成是時間戳+機器碼+進程碼+自增數(shù)，其中機器碼和進程碼都可以一次性生成，這樣得到一個ObjectId僅僅之比自增ID多了一個時間戳的獲取。另外考慮到自增ID都要做主鍵唯一索引，而UUID可以只做索引，不做唯一索引（利用其特性，可以不考慮唯一性過濾），其性能可以說并不比自增ID差。
至于使用UUID還是自增ID主要還是看項目是否足夠龐大，數(shù)據(jù)量是否足夠多。從使用方便性上來說自增ID使用簡單，不需要額外支持，而UUID相對麻煩一些，涉及到UUID算法的選取、程序的嵌入等等。而從應對龐大系統(tǒng)的效果上來說，UUID就比自增ID顯得優(yōu)秀得多。怎么選擇就是看自己的實際情況，按需選擇。
拉莫斯之舞
TA貢獻1820條經(jīng)驗 獲得超10個贊
如果這個 id 會暴露給用戶的話（URL的一部分），那么自增ID 更友好。
性能方面 2 個差距不太大
開發(fā)方便性的話，UUID 比 自增ID 要方便的多
UUID 可以解決分布式ID不沖突，數(shù)據(jù)庫自增ID不支持。
UUID 可以在提交數(shù)據(jù)庫之前就獲取，不需要多一個 select 語句
不是所有數(shù)據(jù)庫都支持自增ID
UUID可以不采用標準的36位長度，可以用base64壓縮到12-16位長度。
優(yōu)先采用UUID方案，如果需要更友好的 URL，也應該采用 sequence 代替自增ID
UUID 標準是 HEX 編碼，改成 BASE64 編碼就變短了.
不是直接把 HEX->BASE64, 而是 HEX->BINARY->BASE64
慕姐4208626
TA貢獻1852條經(jīng)驗 獲得超7個贊
Oracle環(huán)境下（其他數(shù)據(jù)庫沒有使用經(jīng)驗）：
長遠來說，自增Number的占用空間比UUID（raw(16)占用32字節(jié)）更大，但一般表的數(shù)據(jù)量在數(shù)百億以內時number占用的空間還是更少;
UUID使用沒有number方便，UUID存儲為raw(16)時查詢條件需要使用HEXTORAW轉換；
相同行數(shù)情況下，基于UUID的索引占用空間比number更大，數(shù)據(jù)量上去了讀取磁盤次數(shù)肯定就更多了；
并發(fā)或者rac集群環(huán)境下，因為熱塊現(xiàn)象UUID的性能高于number(建立反向索引可解決這個問題)；
UUID使用于前臺展示時更安全，Number可以猜測
慕碼人8056858
TA貢獻1803條經(jīng)驗 獲得超6個贊
上面大部分答案從開發(fā)人員角度比較uuid生成效率，而對數(shù)據(jù)庫的存取效率案例看，用InnoDB或TokuDB的話，答案就是自增主鍵，看看Oracle ACE的這篇解答：
為什么InnoDB表要建議用自增列做主鍵
牧羊人nacy
TA貢獻1862條經(jīng)驗 獲得超7個贊
這個要看你底層存儲的選型，Oracle我不熟，他底層使用rowid來完成，所以不發(fā)表評論。其他類似MongoDB等都有自己特殊性，所以用UUID倒反合適。
但如果你的底層存儲用MySQL，而且存儲引擎又恰好是Innodb，那我是非常推薦你使用唯一自增的數(shù)字來作為你的PK；
首先不去探討UUID和long這兩個數(shù)據(jù)在CPU進行計算時分別對應多少個指令和CPU計算周期，最重要的是Innodb的底層存儲是B+Tree，需要按照一個聚集索引，所有的數(shù)據(jù)查詢操作都是基于聚集索引來完成（如果表設計了PK，則聚集索引默認選用就是這個PK）
如果InnoDB表的數(shù)據(jù)寫入順序能和B+樹索引的葉子節(jié)點順序一致的話，這時候存取效率是最高的。
當然了，如果你的系統(tǒng)不追求性能的極限，那隨便玩
湖上湖
TA貢獻2003條經(jīng)驗 獲得超2個贊
如果是單機， 推薦使用mysql的自增id.
如果是分布式環(huán)境， 想要保持全局的唯一id， 自增和uuid都不行。
這個時候就需要自已定制一套id生成機機制了
繁星coding
TA貢獻1797條經(jīng)驗 獲得超4個贊
這個感覺還是要看具體的場景吧，如果只是一臺數(shù)據(jù)庫服務器的話，并且業(yè)務邏輯并不復雜，完全可以使用自增ID的方式，簡單開發(fā)；如果是僅有少量的幾臺主數(shù)據(jù)庫服務器也可以使用自增ID，但需要做一些處理。
對于分布式的，也就是有多臺主數(shù)據(jù)庫服務器的情況再使用自增ID就會使開發(fā)變得復雜，自增ID會變得越來越難控制，這時候何不用UUID呢，畢竟兩者的性能也沒差多少
添加回答
舉報
0/150
提交
取消