Java EE/SQL：主鍵類型之間是否存在顯着的性能滯後？

Question

目前我參與了學習Java EE技術的一些基礎知識。我遇到了一個特定的項目，並深入研究了底層數據庫結構。 在服務器端，我研究了一個Java函數，該函數創建一個長度爲32個字符的主鍵（基於連接時間，隨機哈希以及附加的加密隨機數）。

我對使用這樣的主鍵導致的性能損失的估計很感興趣。如果沒有安全理由來創建這種獨特的ID，那麼讓底層數據庫創建新的增長初選不會好多少，從0開始？

使用數字而不是字符串時SQL/JQL搜索不會更快嗎？

Answer 1

使用數字可能會更快，但如果您需要兩個選項之間的性能比率，則應使用測試用例來測量它。

我不認爲數字比較vs字符串比較本身會帶來很大的性能優勢。但是：

• 更大的字段通常是指每表塊少的數據，所以必須在全掃描的情況下，以讀取來自DB多個塊（這將是更慢）
• 因此，較大的鍵通常是指更小的鍵每索引塊，所以你必須閱讀更多的索引塊在索引掃描的情況下（它會更慢）
• 更大的字段，以及更大，所以根據定義，它們不太節省空間。

請注意，我們談論的是數據大小而不是數據類型：很可能8字節整數不會比8字節字符串有效得多。

還要注意，使用隨機ID通常比序列號更「可聚集」，因爲序列/自動數字需要集中管理（儘管可以使用諸如Hi-Lo algorithm之類的技術來減輕這個問題。大多數curent持久性框架支持這種技術） 。