我應該使用整數主ID嗎？

Question

例如，我總是爲用戶表生成一個自動增量字段，但我也在其用戶名上指定了一個UNIQUE索引。有些情況下，我首先需要獲取給定用戶名的userId，然後執行所需的查詢，或者在所需的查詢中使用JOIN。它是2次到數據庫或JOIN與varchar索引。

我應該使用整數主ID嗎？

INT是否有真正的性能優勢小 VARCHAR索引？

Answer 1

存在具有代理主鍵，其中的幾個優點：

當你在另一個表的外鍵，如果它是一個整數它佔用只有幾個字節的額外空間，並且可以迅速地加入。如果您使用用戶名作爲主鍵，則必須將它們存儲在兩個表中 - 佔用更多空間，並且需要更長時間才能進行比較。

如果用戶希望更改他們的用戶名，如果您將其用作主鍵，則會遇到很大問題。雖然可以更新主鍵，但這樣做是非常不明智的，並且可能導致各種問題，因爲此鍵可能已發送到各種其他系統，在鏈接中使用，保存在備份中，具有被存檔等等，你不能輕易更新所有這些地方。

Answer 2

這不只是表現。由於在其他地方有詳細記載的原因，您絕對不應該選擇有意義的價值。

順便說一句，我經常縮放int的類型爲表的大小。當我知道表格不會超過255行時，我使用tinyint鍵，smallint也是如此。

Answer 3

除了別人所說的之外，您還需要考慮表格的聚類。

在SQL Server（例如其他供應商）中，如果主鍵也用作表的聚簇索引（這是常見的引用），則增量整數將比其他字段類型有所好處。這是因爲新行使用始終大於前一行的主鍵輸入，這意味着新行可以存儲在表的末尾而不是中間（這種情況下可以與其他一起創建主鍵的字段類型，但整數類型更適合自己）。

將此與guid主鍵進行比較 - 由於guid是非順序的，所以必須將新行插入到表的中間，從而導致插入非常低效。

Answer 4

首先，很明顯，在小桌子上，它對性能沒有影響。只有在非常大的表（有多大取決於許多因素），它可以使的原因有幾個差別：

1. 使用32位將只消耗4個字節的空間。據推測，你的用戶名會比四個非Unicode字符長，因此會消耗超過4個字節的空間。使用的空間越多，頁面上的少量數據就越適合，索引越胖，IO的數量就越多。

2. 除非您強制每個用戶擁有相同大小的用戶名，否則您的字符列將要求使用varchar字符。這也將具有很小的性能和存儲影響。

3. 除非您使用二進制排序歸類，否則系統在比較兩個字符串時必須進行相對複雜的匹配。兩列是否使用相同的相互關係？對於每個角色，他們都是一樣的嗎？匹配方面的外殼和重音規則是什麼？等等。雖然這可以快速完成，但是在一個非常大的表中，與在整數上進行匹配相比，可以做出更多的工作。

我不知道爲什麼你永遠不得不做兩次到數據庫或加入一個varchar列。爲什麼你不能一次去數據庫（創建返回你的新PK），你加入到整數PK的users表中？