我有一些字段的值将是 1 0 的表。这个表将是非常大的超时。使用位数据类型好还是使用不同类型的性能更好?当然,所有字段都应该被索引。
4 回答
我无法为您提供任何有关性能的统计数据,但是,您应该始终使用最能代表您的数据的类型。如果您想要的只是 1-0,那么绝对应该使用位字段。
您可以为数据库提供的信息越多,就越有可能正确地“猜测”。
官方位将是最快的,特别是如果您不允许空值。在实践中它可能并不重要,即使在大量使用时也是如此。但如果值只有 0 或 1,为什么不使用一点呢?听起来是确保该值不会被无效内容(如 2 或 -1)填充的最佳方法。
据我了解,您仍然需要一个字节来存储一个位列(但您可以在一个字节中存储 8 个位列)。因此,拥有大量(多少?)这些位列可以为您节省一些存储空间。正如 Yishai 所说,它可能不会对性能产生太大影响(尽管有一点会更好地转换为应用程序代码中的布尔值)。
如果您可以 100% 自信地声明此列的两个选项永远不会改变,那么请务必使用该位。但是,如果您能看到将来出现第三个值,那么当那天使用 tinyint 时,生活会变得更轻松一些。
只是一个想法,但我不确定索引在此列上对您有多大好处,除非您看到绝大多数行都在一侧或另一侧。在大约 50/50 的分布中,您实际上可能会比在查询表时看到的保持索引更新所受到的影响更大。
这取决于。
如果您想最大化选择的速度,请使用 int(tinyint 以节省空间),因为 where 子句中的 bit 比 int 慢(不是很大,但每毫秒都很重要)。还要使列不为空,这也可以加快速度。下面是实际性能测试的链接,我建议在您自己的数据库上运行它,并通过使用非空值、索引和一次使用多个列来扩展它。在家里,我什至尝试比较使用多个位列与多个 tinyint 列,而 tinyint 列更快(select count(*) where A=0 and B=0 and C=0
)。我认为 SQL Server (2014) 会通过只使用位掩码进行一次比较来优化,所以它应该快三倍,但事实并非如此。如果您使用索引,则需要超过 5000000 行(在测试中使用)才能注意到任何差异(我没有耐心去做,因为在我的机器上填充数百万行的表会花费很长时间)。
如果您想节省空间,请使用 bit,因为其中 8 个可以占用 1 个字节,而 8 个 tinyint 将占用 8 个字节。每百万行节省了大约 7 兆字节。
这两种情况之间的差异基本上可以忽略不计,并且由于使用位具有表明该列仅代表一个标志的优势,因此我建议使用位。