MySQL中的主鍵：INT（n）或UUID as varchar（36）

Question

在UUID中使用UUID作爲主鍵是否合理？

除了手動查詢的麻煩之外，使用UUID代替常規INT的優點和缺點是什麼？

Answer 1

的UUID的主要缺點是，你必須事先創建他們，如果你想重提爲進一步使用記錄之後（即：將在從屬外鍵表子記錄）：

INSERT INTO table (uuidfield, someotherfield) VALUES (uuid(), 'test')); 

將不會讓您看到新的UUID值是什麼，並且由於您沒有使用常規的auto_incremented主鍵，因此無法使用last_insert_id()來檢索它。你必須做一個過程分爲兩個步驟：

SELECT @newuid := uuid(); 
INSERT INTO table (uuidfield, someotherfield) VALUES (@newuid, 'test'); 
INSERT INTO childtable ..... VALUES (@newuid, ....); 

Answer 2

PRO我能想到的是，您的ID將是唯一的，不僅在您的表中，而且在您的數據庫的每個其他表上。而且，它在世界上任何數據庫的任何表格中都應該是唯一的。

如果您的表語義需要該功能，則使用UUID。否則，只需使用簡單的INT ID（更快，更容易處理，更小）。

Answer 3

UUID的缺點是它體積較大，因此搜索速度稍慢。每個即席查詢很難輸入一個很長的十六進制字符串。它解決了您可能沒有的需求，即多服務器唯一性。

順便說一下，INT(n)在MySQL中始終是32位整數，(n)參數與允許值的大小或範圍無關。這只是一個顯示寬度提示。

如果您需要一個整數的值範圍大於32位提供的值，請使用BIGINT。

Answer 4

從我的角度來看，使用UUID MySQL中的主鍵是壞主意，如果我們談論大型數據庫（和大量刀片）。

MySQL始終將主鍵創建爲集羣，並且沒有將其關閉的選項。

考慮到這一點，當您使用非順序標識符（UUID）插入大量記錄時，數據庫會被分段，並且每個新插入操作都會花費更多時間。

建議：使用帶有GUID的PostgreSQL/MS-SQL/Oracle。對於MySQL使用整數（bigints）。