为主键列使用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有什么明显的好处？
正如您可能知道的那样，扫描MEDIUMINT键比扫描INT键快。差异通常不那么大。但是，你的问题对我来说听起来很奇怪：如果你的PK可以是MEDIUMINT，那么任何提到它的FK都应该是MEDIUMINT。 FKs如何包含更大的值？
这是不可能的。目前没有定义外键，我试图添加它们，但在此之前，我希望数据类型同步。 – 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
我能看到的唯一的另一件事是他们有不同的可接受的值范围。除此之外，全部都是关于存储。此外，我不明白为什么员工会在中间，而公司是一个整数。有比公司更多的员工。 – Marc 2013-04-30 16:22:49
除了范围之外，唯一的区别是存储大小：当你有*数百万行时，它可以节省空间，这可以帮助MySQL更快地找到数据，但如果这样做，我不会担心少于几百万行。 – 2013-04-30 16:23:27
如果您仅在几百万行中看到好处，并且您的空间用完了800万，那么除非您确定永远不会破解800万，否则似乎可能不值得。 – 2013-04-30 16:24:45