BIT字段是否比SQL Server中的int字段快?

时间:2009-05-14 22:33:22

标签: sql performance bit

我有一些表格,其中一些字段的值为1 0.这些表格的加班时间非常大。使用bit数据类型或使用不同类型的性能更好吗?当然,所有字段都应编入索引。

4 个答案:

答案 0 :(得分:7)

我无法向您提供有关性能的任何统计信息,但是,您应始终使用最能代表您数据的类型。如果您想要的只是1-0那么绝对应该使用位字段。

您可以为数据库提供的信息越多,就越有可能获得“猜测”。

答案 1 :(得分:2)

正式位将是最快的,特别是如果您不允许空值。在实践中,即使在很大的用途中也可能无关紧要。但如果该值仅为0或1,为什么不使用一点?听起来像是确保该值不会被无效内容填充的最佳方法,如2或-1。

答案 2 :(得分:0)

据我了解,您仍需要一个字节来存储位列(但您可以在一个字节中存储8位列)。因此,拥有大量(多少?)这些位列可以节省一些存储空间。正如Yishai所说,它可能不会在性能方面产生太大的影响(虽然有点会在应用程序代码中更好地转换为布尔值)。

如果您可以100%放心地说明此列的两个选项永远不会改变,那么请务必使用该位。但如果你能看到未来出现第三个值,那么当那天使用tinyint时,它可以让生活变得更轻松。

只是一个想法,但我不确定索引在这个专栏上对你有多好,除非你看到绝大多数行都在一边或另一边。在大约50/50的分布中,您可能实际上需要更多的命中,使索引保持最新状态,而不是您在查询表时看到的增益。

答案 3 :(得分:0)

这取决于。

如果您想选择最大化的速度,使用int(TINYINT为了节省空间),因为在where子句是那么慢int位(不显着,但每毫秒计数)。还要使列不为null,这也可以加快处理速度。下面是链接到实际的性能测试中,我会建议在自己的数据库上运行,并通过使用不空,索引和使用多个列进行扩展。在家里,我什至尝试比较使用多个位列与使用多个tinyint列,并且tinyint列的速度更快(select count(*) where A=0 and B=0 and C=0)。我认为SQL服务器(2014)将这样做只有一个使用位掩码比较优化,所以应该快了3次,但事实并非如此。如果使用索引,您将需要超过5000000行(用于测试)来注意任何差异(我没有耐心做,因为用几百万行填充表会占用我的计算机的时间)。

https://www.mssqltips.com/sqlservertip/4137/sql-server-performance-test-for-bit-data-type-in-a-where-clause/

如果你想节省空间,使用位,因为他们中的8可以ocuppy一个字节,而8个tinyints会按观测8个字节。这大约是保存在行,每行700万兆字节。

那些两种情况之间的差异是可以忽略不计基本上和因为使用位具有上侧的信令,该列代表仅仅是一个标志,我建议使用位