主键为SQL Server BIGINT或十进制（18,0）

我们有一个SQL Server 2005数据库，我们希望提高其大容量删除/插入/选择的性能，我注意到它使用

decimal（18,0）

作为主键。我知道这将给我们带来比

bigint

更多的价值，但我希望这可能是一个快速的胜利，并且根据我的计算，它将持续我们数百万年的增长

我在.net中看到小数取16个字节，而不是long所需的8个字节，但在SQL Server中，它看起来像

bigint

，但

decimal（18,0）

只取16个字节-从表中选择DATALENGTH（max（id））也可以看到这一点。这是正确的吗

---

是否有任何其他原因导致

bigint

速度变慢，或者我应该坚持使用

decimal（18,0）

？

您使用bigint获得此范围：

-2^63 to 2^63-1 

also known as roughly:

-9.2 x 10^18 to 9.2 x 10^18

---

您可以通过十进制（18,0）获得此范围。：

-10^18 to 10^18

十进制：每精度存储字节数

Precision    Storage Bytes
1-9:         5
10-19:       9
20-28:       13
29-38:       17

整数类型和存储字节

integer type    Storage Bytes
bigint          8
int             4
smallint        2
tinyint         1

思想

integer type    Storage Bytes
bigint          8
int             4
smallint        2
tinyint         1

你问题中的两个例子实际上产生了几乎相同数量的唯一值

此外，无论您选择什么，您都不会看到显著的性能变化，但是如果您开始使用小数，而程序员希望使用整数，您将看到团队中其他程序员的效率变化。这是一个小问题

为了解决您的具体问题，如果您想要更大的范围，请使用十进制（38,0）。这将为您提供：

-10^38 to 10^38

如果您担心速度，请使用在软件生命周期内保持的最小精度

如果你不是用纳秒来测量时间，那么选择一个最适合你的程序员的思维方式和你想要拥有一个很长的数字集的愿望的选项

参考资料

integer type    Storage Bytes
bigint          8
int             4
smallint        2
tinyint         1

---

在计算字节数之前，DATALENGTH正在强制转换为varchar。因此，最大值小于100000

这9个字节可以用这个来证明。有一个max_length列（十进制是固定长度的，所以在您询问其他问题之前，它总是9字节）

出于传统原因，

decimal（18,0）

在SQL Server 2000中添加bigint之前，经常被用作“64位整数”的替代项

decimal（18,0）

和

bigint

的范围大致相同：根据文档，decimal在9个字节处多出一个字节

---

最重要的是，纯整数将比十进制快一点点（可能无法测量）。也就是说，如果预计在未来一年或五年内会有超过40亿行，那么表现应该很重要。如果没有，则只需使用

int

在您的情况下，十进制（18,0）需要9个字节，而不是5。DATALENGTH函数表示5？一个bigint适合64位机器上的单个寄存器，9个字节的十进制则不适合。如果我们谈论的是一个到处都在使用的主键，我想这会非常昂贵。