我正在编写一个新程序，它需要一个数据库（SQL Server 2008）。我现在为系统运行的所有东西都是64位，这让我想到了这个问题。对于各种表中的所有Id列，我应该将它们全部设为INT还是BIGINT？我怀疑该系统是否会超越INT范围，但我认为这可能是在一些较大的金融表中。看起来INT虽然是标准......
答案 0 :(得分：107)
好的，让我们快速回顾一下数据：
INT是32位，基本上给你40亿个值 - 如果你只计算大于零的值，它仍然是20亿。你有这么多员工吗？顾客？库存产品？您公司一生中的订单？真？
BIGINT远远超出了它。你真的需要吗？ <强>真？如果你是天文学家，或者是粒子物理学 - 也许。平均业务线用户？我强烈怀疑它
想象一下，你有一张表 - 比如说 - 1000万行（贵公司的订单）。比方说，你有一个Orders表，你创建BIGINT的OrderID被其他5个表引用，并在你的Orders表中的5个非聚集索引中使用 - 我认为没有过度，对吧？
1000万行，5个表加5个非聚集索引，这是1亿个实例，每个实例使用8个字节而不是4个字节--4亿个字节= 400 MB。完全浪费......你需要更多的数据和索引页面，你的SQL Server必须从磁盘读取更多页面并缓存更多页面......这对你的表现没有好处 - 简单明了。
PLUS：大多数程序员不会考虑的事情：是的，磁盘空间很便宜。但是，浪费的空间也与SQL Server RAM内存和数据库缓存相关 - 而且这个空间并不便宜！
所以要做一个很长的帖子：使用最适合你需要的INT类型;如果要处理10-20个不同的值 - 使用TINYINT。如果你需要一个订单表，我相信INT应该 PLENTY ENOUGH - BIGINT只是浪费空间。
另外：如果您的任何表格真的接近达到2到40亿行，您仍然有足够的时间将表格升级为BIGINT ID，如果确实需要的话......
答案 1 :(得分：14)
您应该使用对相关表有意义的最小数据类型。这包括在行数不足的情况下使用smallint甚至tinyint。
您将节省数据和索引的空间并获得更好的索引性能。当您需要的只是bigint时smallint类似于使用varchar(4000)，只需varchar(50)。
即使机器的本机字大小为64位，这也只表示64位CPU操作不会比32位操作慢 。大多数时候，他们也不会更快，他们会是一样的。但是大多数数据库都不会受到CPU限制，它们将受到I / O限制，并且在较小程度上受内存限制，所以当你需要执行一个数据时，50％-90％的数据大小是非常好的。索引扫描超过2亿行。
答案 2 :(得分：13)
这篇文章有一些关于性能的真实答案......如果可能，我更愿意用硬数字回答问题...如果你点击以下链接至少有一百万条记录，你会发现磁盘上的差异可以忽略不计用法....
http://www.sqlservercentral.com/articles/Performance+Tuning/2753/
就我个人而言，我确实认为使用适当的ID大小很重要，但也要考虑到这样一个事实，即您可能会有一张表随着时间的推移有大量活动。这不是存储大量数据，而是由于自动递增的性质（随时间发生删除和插入）而导致密钥值增加。
考虑社区网站上的文件存储库，或社区网站多租户应用程序上的用户注释的ID。
据我所知，大多数开发人员正在构建永远不会触及数百万条记录的系统，但重要的是要注意有必要使用bigint的原因，而且我仍然不相信当你设计一个模式时不知道潜在的增长，你不应该试图预测未来，如果你觉得随着id值的增长潜力超过int的最大值，可以考虑使用bigint。
答案 3 :(得分：6)
将32位数字与x86架构或64位与x64架构对齐称为data structure alignment
这对数据库中的数据没有意义，因为这会影响性能的磁盘空间，数据缓存和表/索引体系结构（如其他答案中所述）。
请记住，这不是CPU访问数据。它是在CPU上运行并操纵数据的数据库引擎代码（可能是对齐的，但是谁在乎？）。当/如果您的数据通过CPU时，它肯定不会在相同的磁盘结构中。
答案 4 :(得分：6)
其他人已经为32位ID提供了令人信服的答案。
对于某些应用程序，64位ID确实更有意义。
如果要保证ID在数据库集群中是唯一的 - 对于ID，63位可以非常方便。使用32位，很难在群集中的服务器之间分配ID的生成;或跨数据中心。虽然64位有足够的空间可以使用，但您可以方便地在服务器上生成ID而无需锁定，并且仍然保证唯一性。
例如，请参阅Twitter Snowflake和Instagram Engineering's blog post on "Sharding & IDs at Instagram"。两者都提供了很好的理由，为什么63或64位的ID比32位计数器更有意义。
答案 5 :(得分：4)
您应该分别判断每个表的数据类型是否满足每个表的需求。如果INTEGER满足特定表的需要，请使用它。如果SMALLINT就足够了，请使用它。使用将持续的数据类型，而不会过多。
答案 6 :(得分：4)
第一个答案是任何不使用TB大小数据库或具有常量和高容量插入的表的人的天真答案。在任何体面的大小数据库中，您将在其生命周期的某个阶段遇到INT问题。如果必须的话，请使用BIGINT，因为它可以进一步节省大量麻烦。我看到公司在仅仅一年的数据后就遇到了INT问题，并且重新选择不是一种选择，导致了大量的停机时间。此外，在长期运行的系统（10年+）中，预计系统不会被使用，即使使用中等大小的数据库清除旧数据，也会受到影响。在大多数情况下使用GUID要好得多，在大多数情况下需要大量数据，但如果需要，禁止使用BIGINT。