uuid作為主鍵，還是用自增呢？

我在網上找了好久，有的人說uuid比較好，就是在分庫分表，合并資料什麼的比較容易，也有的人說自增好，到了表的資料多的時候，效能比uuid好得多，到底那種比較好呢？有沒有在真實生產環境的大神，來給出一個完整的解答？

回複內容：

我在網上找了好久，有的人說uuid比較好，就是在分庫分表，合并資料什麼的比較容易，也有的人說自增好，到了表的資料多的時候，效能比uuid好得多，到底那種比較好呢？有沒有在真實生產環境的大神，來給出一個完整的解答？

首先UUID的效能並不比自增ID差很多，這取決於UUID的產生演算法。舉個例子MongoDB所採用的ObjectId就是一個比較優秀的UUID策略，其組成是時間戳記+機器碼+進程碼+自增數，其中機器碼和進程碼都可以一次性產生，這樣得到一個ObjectId僅僅之比自增ID多了一個時間戳記的擷取。另外考慮到自增ID都要做主鍵唯一索引，而UUID可以只做索引，不做唯一索引（利用其特性，可以不考慮唯一性過濾），其效能可以說並不比自增ID差。

至於使用UUID還是自增ID主要還是看項目是否足夠龐大，資料量是否足夠多。從使用方便性上來說自增ID使用簡單，不需要額外支援，而UUID相對麻煩一些，涉及到UUID演算法的選取、程式的嵌入等等。而從應對龐大系統的效果上來說，UUID就比自增ID顯得優秀得多。怎麼選擇就是看自己的實際情況，按需選擇。

Oracle環境下（其他資料庫沒有使用經驗）：
長遠來說，自增Number的佔用空間比UUID（raw(16)佔用32位元組）更大，但一般表的資料量在數百億以內時number佔用的空間還是更少;
UUID使用沒有number方便，UUID儲存為raw(16)時查詢條件需要使用HEXTORAW轉換；
相同行數情況下，基於UUID的索引佔用空間比number更大，資料量上去了讀取磁碟次數肯定就更多了；
並發或者rac叢集環境下，因為熱塊現象UUID的效能高於number(建立反向索引可解決這個問題)；
UUID使用於前台展示時更安全，Number可以猜測

1. 如果這個 id 會暴露給使用者的話（URL的一部分），那麼自增ID 更友好。

2. 效能方面 2 個差距不太大

3. 開發方便性的話，UUID 比 自增ID 要方便的多

   • UUID 可以解決分布式ID不衝突，資料庫自增ID不支援。

   • UUID 可以在提交資料庫之前就擷取，不需要多一個 select 語句

   • 不是所有資料庫都支援自增ID

4. UUID可以不採用標準的36位長度，可以用base64壓縮到12-16位長度。

5. 優先採用UUID方案，如果需要更友好的 URL，也應該採用 sequence 代替自增ID

上面大部分答案從開發人員角度比較uuid產生效率，而對資料庫的存取效率案例看，用InnoDB或TokuDB的話，答案就是自增主鍵，看看Oracle ACE的這篇解答：
為什麼InnoDB表要建議用自增列做主鍵

按需所取，具體問題具體分析，簡單的說,一般 32位元組的UUID 可以通用

自增在索引上有優勢（整型的比較比字串比較要快），但優勢有限。兩者的區別最主要在於id是在client端/server端產生。 相對於mysql來說，java程式就是一個client端。uuid可以保證client端產生一個唯一且不重複的id，這在分布式系統中非常重要。

如果你摸不準的話，我建議你使用uuid.

這個要看你底層儲存的選型，Oracle我不熟，他底層使用rowid來完成，所以不發表評論。其他類似MongoDB等都有自己特殊性，所以用UUID倒反合適。

但如果你的底層儲存用MySQL，而且儲存引擎又恰好是Innodb，那我是非常推薦你使用唯一自增的數字來作為你的PK；

首先不去探討UUID和long這兩個資料在CPU進行計算時分別對應多少個指令和CPU計算周期，最重要的是Innodb的底層儲存是B+Tree，需要按照一個叢集索引，所有的資料查詢操作都是基於叢集索引來完成（如果表設計了PK，則叢集索引預設選用就是這個PK）

如果InnoDB表的資料寫入順序能和B+樹索引的葉子節點順序一致的話，這時候存取效率是最高的。

當然了，如果你的系統不追求效能的極限，那隨便玩

為什麼不定製自己的主鍵策略呢？

mysql的使用自增的，不然innodb也要自己維護主鍵索引的。

如果是單機， 推薦使用mysql的自增id.

如果是分布式環境， 想要保持全域的唯一id， 自增和uuid都不行。
這個時候就需要自已定製一套id產生機機制了

【注意】
我遇到過GUID重複，所以，直接用GUID做唯一主鍵是有潛在問題的！

（GUID是UUID標準的一種實現）

這個感覺還是要看具體的情境吧，如果只是一台資料庫伺服器的話，並且商務邏輯並不複雜，完全可以使用自增ID的方式，簡單開發；如果是僅有少量的幾台主要資料庫伺服器也可以使用自增ID，但需要做一些處理。

對於分布式的，也就是有多台主要資料庫伺服器的情況再使用自增ID就會使開發變得複雜，自增ID會變得越來越難控制，這時候何不用UUID呢，畢竟兩者的效能也沒差多少

