在 MySQL 中为 BIT(n) 属性创建索引有意义吗？

Question

我正在处理一个非常具体的事情，我需要使用BIT(n)属性并有效地搜索它们。n通常不是 2 的幂。

我在互联网上看到一些提到BIT属性在 MySQL 中对索引不友好。虽然没有进一步阐述。

所以问题是 - MySQL 索引是否可以很好地与BIT(n)属性配合使用，或者我最好找到一些其他方法，例如限制n为 32 并INT改为使用？

Answer 1

除非您要查询存储在位列中的整个值的精确匹配，否则索引将无济于事，因为它通常不能使用。如果你是遥远的机会，那么它会。

在存储位图值然后根据一位或多位的状态进行查询时不能使用索引的原因包括以下事实：MySQL 中常用的索引类型仅用于精确值或范围匹配，以及按位比较并不是真正的其中任何一种。

由于此限制的性质，如果您使用任何整数数据类型甚至 SET 数据类型，它也适用。

例如，测试一个 8 位数字的高位状态与测试数字是否 >= 128 相同，这确实是一个范围匹配，可以使用 b 树索引来完成，但是使用此测试的索引，优化器必须了解这是您“真正”询问的内容，当您实际要求的是 WHERE bin_col & b'10000000' ......优化器不会意识到那。

我倾向于使用 UNSIGNED [something]INT 列来存储位图值，因为 MySQL 中的 BIT 列实际上更类似于 CHAR/BINARY 列而不是整数数据，但这最终将取决于您的应用程序以及你的存储引擎。

MyISAM 显然将不同的位列一起存储在原始行数据中，因此如果您不使用 8/16/32/64 的偶数增量，则在使用 BIT 与 INT 时可能会有一个小的存储优势 - 但除非您已经在使用 MyISAM，我认为这不足以让您考虑使用它。

MEMORY 和 InnoDB 引擎分配可以在 BIT 列中容纳所需位数的最小标准整数大小。

SET 数据类型还将值存储为 1、2、3、4 或 8 字节的无符号整数，这取决于您为位定义的标签数量。当您查看存储的位图数据时，它更容易吸引眼球，因为如果您从中选择而不将结果转换回整数（使用 SELECT column_name + 0 显式或隐式），您将返回一个逗号分隔的设置为“on”的位标签列表......它不提供任何查询优化，但与使用原始整数相比，它确实可以增强将您的位扩展到标签而没有任何实际损失柱子。