我们有一个SQL Server 2005数据库,我们想要提高批量删除/插入/选择的性能,我注意到它使用decimal(18,0)
作为主键。我理解这将给我们提供比bigint
更多的价值,但希望它可能是一个快速的胜利,并且应该通过我的计算让我们持续数百万年的增长。
我在.net docs小数中看到16个字节而不是long所需的8个字节,但在SQL Server中它看起来像bigint
take 8 bytes但decimal(18,0)
需要只有5 bytes - select DATALENGTH(max(id)) from table
也可以看到。这是对的吗?
是否还有其他原因bigint
可能较慢或我应该坚持decimal(18,0)
?
答案 0 :(得分:21)
您使用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
<强>思想强>
您的问题中发布的两个示例实际上产生了几乎相同数量的唯一值。
此外,无论您的选择如何,您都不会看到显着的性能变化,但如果您开始使用程序员期望整数的小数,您将看到团队中其他程序员的效率发生变化。这是一个小问题。
要解决您的具体问题,如果您想要更大的范围,请使用十进制(38,0)。这给你:
-10^38 to 10^38
如果您担心速度,请使用将持续软件生命周期的最低精度。
如果您没有以毫秒为单位测量时间,那么请选择最适合您的程序员心态的选项以及您希望拥有一组很长的数字。
<强>参考强>
答案 1 :(得分:7)
在计算字节数之前,DATALENGTH正在转换为varchar。所以你的最大值是&lt; 100000.
可以用这个证明9个字节。 sys.columns有一个max_length列(十进制是固定长度所以它总是9个字节,在你另外要求之前)
CREATE TABLE dbo.foo (bar decimal(18,0))
GO
SELECT * FROM sys.columns WHERE object_id = OBJECT_ID('foo')
GO
DROP TABLE dbo.foo
GO
由于遗留原因,在使用SQL Server 2000添加bigint之前,decimal(18, 0)
经常被用作“64位整数”的代理。
decimal(18, 0)
和bigint
的范围大致相同:根据文档
除此之外,普通整数将比小数快一些(可能不可测量)。如果说,如果预计明年或5年将有超过40亿行,那么表现应该是重要的。如果没有,那么只需使用int