SQL Server Int或BigInt数据库表ID

我梦随风

我正在编写一个新程序，它将需要一个数据库（SQL Server
0 @* o& K# `, A& ^9 _& j2008）。我现在为该系统运行的所有内容都是64位的，这使我想到了这个问题。对于各种表中的所有Id列，我应该将它们全部设置为INT还是BIGINT？我怀疑该系统是否会超过INT范围，但是我认为某些较大的财务表中可能会出现这种情况。似乎INT是标准的…
               
# V; V6 K% j8 \  F) f7 N解决方案:
9 t. \" s2 \6 E' L* {+ Q               

$ o- l' |; B, Q" s. l% I
                好的，让我们快速回顾一下数学：
, Y, J- n4 S" a, F$ U' q
INT是32位的，基本上为您提供40亿个值-如果仅计算大于零的值，则仍为20亿个值。你有这么多员工吗？顾客？产品有存货吗？在您公司生命周期内的订单？真的吗？
/ {2 K2 F( z2 G. ?% G  o
BIGINT远远超出了这一范围。您真的需要吗？ 真的 吗?? 如果您是天文学家，或者是粒子物理学的-也许。普通业务用户？我对此表示强烈怀疑

1 G( o/ g" J7 l* T+ [! K6 s
假设您有一个表-
# F* \2 Y" D: i4 a假设有-1000万行（贵公司的订单）。假设您有一个Orders表，并且其他5个表引用了您作为BIGINT生成的OrderID，并在Orders表中的5个非聚集索引中使用了-
  W1 w3 i: K  i我认为不要过度，对吧？
) O4 e! |# g) _. G9 h! n1000万行，由5个表加上5个非聚集索引组成，这是1亿个实例，其中每个实例使用8个字节而不是4个字节-4亿个字节= 400
MB。完全浪费…您将需要更多的数据和索引页，您的SQL Server将不得不从磁盘读取更多的页面并缓存更多的页面....这对您的性能没有好处-简单明了。
9 t- ]% M( D7 |. l# O/ o0 q加上：大多数程序员不会考虑的问题：是的，磁盘空间非常便宜。但这浪费的空间在SQL Server RAM内存和数据库缓存中也很重要-而且这个空间并不便宜！
因此，要写一篇很长的文章，请使用最适合您需求的最小类型的INT；如果您要处理10-20个不同的值，请使用TINYINT。如果您需要订单表，我相信INT应该足够
丰富-BIGINT 只是浪费空间。
另外：如果您的表中的任何一个确实要达到2或40亿行，如果确实需要，您仍然有足够的时间将表升级到BIGINT ID。