由於某些原因,在存入數據庫之前需要獲得UUID
。類java.util.UUID
可用於此。但是將這個生成的id用作數據庫中的主鍵還是安全的,或者uuid只能由db生成?是否安全使用java來生成UUID主鍵?
注意 實際使用MySql,但我不認爲它可以影響問題的答案。
由於某些原因,在存入數據庫之前需要獲得UUID
。類java.util.UUID
可用於此。但是將這個生成的id用作數據庫中的主鍵還是安全的,或者uuid只能由db生成?是否安全使用java來生成UUID主鍵?
注意 實際使用MySql,但我不認爲它可以影響問題的答案。
在UUID生成的地方,只要它們是唯一的,它確實不會有什麼區別。 MySQL的內置UUID()
函數沒有什麼特別之處。
但是,這個問題一般與UUID有關。在InnoDB中(這就是應該使用),主鍵是聚簇索引......這意味着行的物理存儲是以主鍵順序存儲的......這意味着在考慮任何時間行時性能會受到影響沒有以主鍵順序插入到表中。你的表中會有大量的頁面拆分和大量的碎片。而且,顯然,如果您連續生成多個UUID,則顯然它們不是詞彙順序的。
此外,特別是如果你存儲一個UUID爲36個字符的CHAR
或VARCHAR
那麼你的加入將是36個字節的值,這給自己帶來潛在的性能問題 - 相反與INT
,這是唯一4個字節或BIGINT
,即8個。外鍵約束檢查也必須使用較大的值。
AUTO_INCREMENT
主鍵解決了這兩個問題,因爲根據定義,行是按主鍵順序插入的,並且鍵由較少的字節組成,這應該意味着更好的聯接性能。
表演會不會太糟糕?不,但它不會是最佳的。
但是,要回答這個問題,UUID的生成方式或位置應該沒有關係。事實上,UUID的動機之一就是它們應該是獨一無二的,而不管其來源。
感謝無論如何,對於沒有解釋的駕駛者反對票。這是「有用的」。 –
在這種情況下定義安全 –
定義'出於某種原因'。如果可能的話,讓數據庫定義自己唯一的密鑰總是更好。 – EJP
如果我是你,我會省下麻煩,只需打開自動增量。但是,是的,它應該是安全的。 – 4castle