爲主鍵列使用mediumint而不是int的好處？

我繼承了一個數據庫，其中以前的開發人員對關鍵列使用了mediumint和int的混合。我正在瀏覽數據庫並嘗試添加外鍵，並且由於各個表上的鍵列之間的類型不匹配，我遇到了一些問題。爲主鍵列使用mediumint而不是int的好處？

實施例：

Company 
-------- 
Id (int) 
Name (whatever) 

Employee 
--------- 
Id (mediumint) 
CompanyId(mediumint) 
Name (whatever)

From what I understand，使用mediumint將節省存儲箱中的一個字節（也限制我有點超過800萬行）。

我寧願將所有內容移動到int，但我想知道是否會有使用mediumint而不是int有什麼明顯的好處？

我能看到的唯一的另一件事是他們有不同的可接受的值範圍。除此之外，全部都是關於存儲。此外，我不明白爲什麼員工會在中間，而公司是一個整數。有比公司更多的員工。 – Marc 2013-04-30 16:22:49

除了範圍之外，唯一的區別是存儲大小：當你有*數百萬行時，它可以節省空間，這可以幫助MySQL更快地找到數據，但如果這樣做，我不會擔心少於幾百萬行。 – 2013-04-30 16:23:27

如果您僅在幾百萬行中看到好處，並且您的空間用完了800萬，那麼除非您確定永遠不會破解800萬，否則似乎可能不值得。 – 2013-04-30 16:24:45

正如您可能知道的那樣，掃描MEDIUMINT鍵比掃描INT鍵快。差異通常不那麼大。但是，你的問題對我來說聽起來很奇怪：如果你的PK可以是MEDIUMINT，那麼任何提到它的FK都應該是MEDIUMINT。 FKs如何包含更大的值？

2013-04-30 16:38:51

這是不可能的。目前沒有定義外鍵，我試圖添加它們，但在此之前，我希望數據類型同步。 – 2013-04-30 16:41:48

當然。但是，假設你打算製作這個FK：tab1.a - > tab2.a.如果MAX（tab1.a）> 65535，那麼MAX（tab2.a）也應該> 65535。那麼，將這兩列更改爲MEDIUMINT會出現什麼問題？ – 2013-05-01 20:46:35

在這種情況下沒有問題。如果你使用mediumint來創建一個可能有一天超過800萬行的表，那麼問題就來了。我認爲，由於我使用'int'而不是'mediumint'，我遇到性能問題的機會比我更大。 – 2013-05-01 21:16:09

回答