好的，让我们快速回顾一下数学：

• INT是32位的，基本上为您提供40亿个值-如果仅计算大于零的值，则仍为20亿个值。你有这么多员工吗？顾客？产品有存货吗？在您公司生命周期内的订单？真的吗？

• BIGINT远远超出了这一范围。您真的需要吗？ 真的 吗?? 如果您是天文学家，或者是粒子物理学的-也许。普通业务用户？我对此表示强烈怀疑

假设您有一个表-
假设有-1000万行（贵公司的订单）。假设您有一个Orders表，并且其他5个表引用了您作为BIGINT生成的OrderID，并在Orders表中的5个非聚集索引中使用了-
我认为不要过度，对吧？

1000万行，由5个表加上5个非聚集索引组成，这是1亿个实例，其中每个实例使用8个字节而不是4个字节-4亿个字节= 400
MB。完全浪费…您将需要更多的数据和索引页，您的SQL Server将不得不从磁盘读取更多的页面并缓存更多的页面....这对您的性能没有好处-简单明了。

加上：大多数程序员不会考虑的问题：是的，磁盘空间非常便宜。但这浪费的空间在SQL Server RAM内存和数据库缓存中也很重要-而且这个空间并不便宜！

因此，要写一篇很长的文章，请使用最适合您需求的最小类型的INT；如果您要处理10-20个不同的值，请使用TINYINT。如果您需要订单表，我相信INT应该足够
丰富-BIGINT 只是浪费空间。

另外：如果您的表中的任何一个确实要达到2或40亿行，如果确实需要，您仍然有足够的时间将表升级到BIGINT ID。