SQL Server：varbinary 或 int 存储位掩码？答案

【问题标题】：SQL Server: varbinary or int to store a bit mask?SQL Server：varbinary 或 int 存储位掩码？
【发布时间】：2009-04-30 22:17:03
【问题描述】：

就性能或灵活性而言，使用 int 与 varbinary 存储位掩码有什么优势吗？

出于我的目的，我将始终对这些位掩码进行读取（不写入或更新）。

【问题讨论】：

标签： sql sql-server database-design bitmask

【解决方案1】：

您绝对应该使用INT（如果您需要 32 个标志）或BIGINT（对于 64 个标志）。如果您需要更多标志，可以使用BINARY（但您可能还应该问自己，为什么您的应用程序中需要这么多标志）。

另外，如果使用整型，可以直接使用标准的bitwise operators，无需将字节数组转为整型。

如果您确实需要更多标志并且必须使用BINARY，您将失去对位运算符的原生支持，因此无法轻松支持检查标志值。我可能会将检查标志值转移到客户端应用程序，但如果您习惯使用 T-SQL 编程，这也是一个选项。如果您使用 C#，则您有一个 BitArray 类，其中包含必要的操作，而在 Java 中，您有一个 BitSet 类。

【讨论】：

是的，或者更小的类型比如 tiny int 用于更小的位掩码？我从来没有使用过小的 int 作为位掩码，但应该没问题。 int 的工作很棒。
当我们有例如 100 个标志时，我们如何使用 varbinary？ varbinary 可以像 int 或 bigint 一样灵活使用吗？不能对两个 varbinary 进行按位运算。我们如何模仿 int-flag 的行为？
我会为此使用 BINARY(13)（有 104 位/标志的空间）。但是，您失去了对位运算符的本机支持。我更新了我的答案以提供一些选项。

【解决方案2】：

通常认为最好使用一组位列而不是位掩码。它们将在页面中打包在一起，因此它们不会占用更多空间。虽然我似乎也总是使用 int 或 bigint 列来避免输入所有列名。但使用智能感知我可能会使用位列。

【讨论】：

我不同意，位掩码仍然占有一席之地，它们是让您的选项保持开放的好方法，而无需重构您的数据库和 SELECTS/VIEWS/SPROCS 只需添加一个简单的布尔值，它们非常灵活... 只是大多数程序员现在都不了解他们是什么
程序员的无知有时表明我们在将引擎和框架内部的低级优化抽象化方面取得了不错的进展。单个位字段： 1. 由引擎有效处理（打包在一起，由本机代码而不是 TSQL 操作）。 2. 具有有意义的名称，使您的查询更易于理解（而不是使用任意位索引号）。 3. 可以在它们上面放置索引，加速查询。 4. 可以有单独配置的默认值。 5. 如果您决定该字段需要两个以上的状态，则以后更容易重构为更大的类型。等
没错。 SQL 中的位掩码只会扼杀 SQL 的功能——您将永远无法有效地查询它们。因此，它们不应该被使用。
至少有一种情况需要位掩码字段：索引被限制为 16 列，使用一组标志或一系列打包值可能会超过该列。
@JonofAllTrades 该限制仅适用于构成索引键的列（您可以将位添加为包含列并仍然对其进行谓词）。您是否遇到过在索引的键中包含超过 16 个布尔值很有用的情况？

【解决方案3】：

好吧，考虑到 int 的存储空间较小，并且通常使用起来更容易一些，我不确定您为什么要使用 varbinary。

【讨论】：

【解决方案4】：

我通常同意@hainstech 使用位字段的回答，因为您可以明确命名每个位字段以指示它应该存储的内容。但是，我还没有看到与位字段进行位掩码比较的实用方法。使用 SQL Server 的按位运算符（&、| 等），很容易找出是否设置了一系列标志。使用等式运算符针对大量位字段进行更多工作。

【讨论】：

除了... 位运算符 FORCE A TABLE SCAN 会降低性能，同时可以有效地查询单个位字段。