【发布时间】：2010-01-23 20:43:07
【问题描述】：
我正在编写一个新程序，它需要一个数据库 (SQL Server 2008)。我现在为系统运行的所有东西都是 64 位的，这让我想到了这个问题。对于各种表中的所有 Id 列，我应该将它们全部设为 INT 还是 BIGINT？我怀疑该系统是否会超过 INT 范围，但我认为在一些较大的财务表中是有可能的。看起来 INT 是标准的...
【问题讨论】：
标签： sql sql-server
【发布时间】：2010-01-23 20:43:07
【问题描述】：
好的，让我们快速回顾一下数学：
INT 是 32 位的，基本上可以提供 40 亿个值 - 如果只计算大于零的值，它仍然是 20 亿个。你有这么多员工吗？顾客？产品有库存吗？贵公司生命周期内的订单？真的吗？
BIGINT 远不止于此。你真的需要那个吗？？ 真的？？如果你是天文学家，或者研究粒子物理学——也许吧。普通的业务线用户？我强烈怀疑
假设您有一张表，其中包含 - 比方说 - 1000 万行（贵公司的订单）。假设您有一个 Orders 表，并且您创建 BIGINT 的 OrderID 被其他 5 个表引用，并在您的 Orders 表上的 5 个非聚集索引中使用 - 我认为没有过度，对吧？
1000 万行，由 5 个表加上 5 个非聚集索引，即 1 亿个实例，每个实例使用 8 个字节而不是 4 个字节 - 4 亿字节 = 400 MB。完全浪费...您将需要更多数据和索引页面，您的 SQL Server 将不得不从磁盘读取更多页面并缓存更多页面....这对您的性能没有好处 - 简单明了。
另外：大多数程序员没有想到的是：是的，磁盘空间非常便宜。但是，浪费的空间也与您的 SQL Server RAM 内存和数据库缓存相关——而且这些空间并不便宜！
所以要使一个很长的帖子简短：使用真正适合您需要的最小类型的 INT；如果您有 10-20 个不同的值要处理 - 使用 TINYINT。如果您需要订单表，我认为 INT 应该是 PLENTY ENOUGH - BIGINT 只是浪费空间。
另外：如果您的任何表真的接近 2 或 40 亿行，您仍然有足够的时间将表升级到 BIGINT ID，如果确实需要的话......。
【讨论】：
-
我实际上必须执行这样的更新，你是对的，我们有超过 6 个月的警告，这并不难。具有讽刺意味的是，整个密钥将在下一个版本中消失，因为它确实没有必要。通常我讨厌自然键，但是当你的表中有数十亿行时，是时候开始考虑它们了；在插入 50,000 多行时，多 100 GB 可用磁盘空间和少一个要更新的索引是非常好的激励措施。
-
考虑 ATT：假设有 1 亿客户，每天 1 条文本，持续 30 天，即 30 亿条记录需要一个 id 字段才能使用一个月。我在一家手机公司（不是ATT）工作，我觉得你解雇bigint是不必要的，缺乏想象力。对于像手机服务这样的日常和平凡的东西，ints 是不够的。话虽如此，我很欣赏你所说的一切。
-
@user38858：所以使用
BIGINT身份，这对于AT&T 来说仅适用于大约300 万个月...... -
我给出了一个相关且真实的例子，说明
int是不够的。我不确定你为什么选择对此嗤之以鼻。如果你对这个例子有些疑虑，或者你认为你有理由int足以用于手机元数据，请告诉我。我一直希望在工作中做得更好。 -
这是一个老话题，但没关系。在 int 或 bigint 之间进行选择时，您需要考虑，如果您想不断移动行，而不重复使用已删除的键（就像您将其传输到存档，因此它会从某个表中删除，但您想要将密钥保留在整个系统中而不是复制它们）。
您应该使用对相关表有意义的最小数据类型。这包括使用smallint 甚至tinyint（如果行数足够少）。
您将节省数据和索引空间并获得更好的索引性能。当您只需要 smallint 时使用 bigint 类似于在您只需要 varchar(50) 时使用 varchar(4000)。
即使机器的本机字长为 64 位，这也仅意味着 64 位 CPU 操作不会比 32 位操作慢。大多数时候，它们也不会更快，它们会是一样的。但是大多数数据库无论如何都不会受 CPU 限制，它们会受 I/O 限制，并且在较小程度上受内存限制，因此当您需要执行索引扫描超过 2 亿行。
【讨论】：
-
@Aaronaught 好帖子+1，快速提问；我的印象是，对于小于 50 的给定字符串，varchar(50)、varchar(4000) 和 varchar(max) 都占用了相同的空间，区别仅在于 SQL 对字段大小的限制可。 (msdn.microsoft.com/en-us/library/aa258242(SQL.80).aspx)
-
@Hogan：好点。为了准确描述域需求，合理的最大尺寸更好，但更好的类比可能是
char(10)与char(50)。
这是一篇关于性能的真实答案的文章...如果可能的话，我更喜欢用硬数字回答问题...如果您单击以下链接至少多达一百万条记录，您会发现磁盘上的差异可以忽略不计用法....
http://www.sqlservercentral.com/articles/Performance+Tuning/2753/
我个人认为使用适当的 ID 大小很重要，但也要考虑这样一个事实，即随着时间的推移，您的表可能会有大量活动。并不是您存储了大量数据，而是由于自动递增的性质（随着时间的推移发生删除和插入），键值已经增长。
考虑社区站点上的文件存储库，或社区站点多租户应用程序上的用户 cmets 的 ID。
我知道大多数开发人员正在构建永远不会触及数百万条记录的系统，但重要的是要注意，需要 bigint 是有原因的，而且我仍然不相信当您设计架构时，您不知道潜在的增长，您不应该尝试预测未来，如果您认为随着 id 值的增长，有可能超过 int 的最大值，请考虑使用 bigint。
【讨论】：
-
请添加链接文章中的相关信息，因为它不可用，似乎需要注册。
-
不再需要注册\o/
32位数字与x86架构或64位与x64架构的对齐称为data structure alignment
这对数据库中的数据没有意义，因为影响性能的是磁盘空间、数据缓存和表/索引架构（如其他答案中所述）。
请记住，访问数据的不是 CPU。它是在 CPU 上运行并操作您的数据的数据库引擎代码（可能是对齐的，但谁在乎呢？）。当/如果您的数据通过 CPU 时，它肯定不会位于相同的磁盘结构中。
【讨论】：
其他人已经对 32 位 ID 给出了令人信服的答案。
对于某些应用程序，64 位 ID 确实更有意义。
如果您想保证 ID 在数据库集群中是唯一的 - 63 位的 ID 会非常方便。对于 32 位，很难在集群中的服务器之间分发 ID 的生成；或跨数据中心。虽然使用 64 位，但您有足够的空间来使用，您可以方便地跨服务器生成 ID，而无需锁定，并且仍然保证唯一性。
例如，请参阅 Twitter Snowflake 和 Instagram Engineering's blog post on "Sharding & IDs at Instagram"。两者都提供了很好的理由，为什么 63 或 64 位对它们的 ID 比 32 位计数器更有意义。
【讨论】：
您应该单独判断每个表的数据类型可以满足每个表的需要。如果 INTEGER 可以满足特定表的需求，请使用它。如果 SMALLINT 就足够了，请使用它。使用会持续的数据类型，但不要过多。
【讨论】：
对于不使用 TB 大小的数据库或具有恒定和高容量插入的表的人来说，第一个答案是天真的答案。在任何大小合适的数据库中，您都会在 INT 生命周期的某个阶段遇到问题。如果必须，请使用 BIGINT，因为它会进一步节省很多麻烦。我已经看到公司在仅仅一年的数据后就遇到了 INT 问题，并且在无法重新播种的情况下，它会导致大量停机。此外，在预计不会继续使用该系统的长期运行系统（10 年以上）中，即使使用清除旧数据的中等大小的数据库也会受到打击。在大多数情况下使用 GUID 会好得多，如果需要大量数据，但除非需要使用 BIGINT。
【讨论】：