Question

我需要在MySQL表中存储冗长的位串，这些位串可能长达32768位。此数据需求不需要随时被索引或全文搜索。如果我已经正确阅读，这个大小应该在我的max_packet_size以及行大小限制@ 65k内。

理想情况下，我想以0b格式存储字符串（并插入它们），但这不是必需的......任何能够在磁盘上提供基本上1：1数据/大小的东西都会很棒。

BLOB似乎不能很好地完成这项工作，因为只包含1和0（'010101010101'）的字符串与普通文本没有区别，并且花费我L字节+ 2.BIT（）将是完美的，但仅限于64位最大长度。

尽管大部分数据（90％以上）都会在无符号Bigint中充分表示，但其余10％的行会让我找到一个更优雅的解决方案，而不是逻辑上将它们拆分（即，如果不是，则搜索辅助表）在第一个辅助表中找到，使用BLOB来保留剩余的10％行等。）

额外的好处是允许按位操作的任何类型，但如果没有，这在MySQL服务器之外就可以轻松完成。

为此目的，最有效的数据类型是什么？

Answer 1

我会说这主要取决于您的访问模式。如果你能够在每次访问时读取/写入整个位串，那么varbinary（4096）将正常工作并且非常紧凑（整个字段只有2个字节的开销）。在这个模型中，应用程序端的一位实际上由数据存储中的一位表示，并且由客户端应用程序将其解释为位串（执行按位操作等等）。

如果你想进一步优化，你可以想象一个带有bigint和varbinary（4096）的表：

create table dummy (
   dummykey int not null,
   bit1 bigint null,
   bit2 varbinary(4096) null,
   primary key(dummykey)
);

对于给定记录，两个字段中只有一个不为null。如果bit1不为null，则它可以存储64位。对于较大的位串，bit1为空，而使用bit2。客户端应用程序必须足够智能以处理所有按位操作（特别注意bit1的签名/未签名问题）。

Answer 2

我猜BLOB类型就是你需要的。它可以表示最多2 ^ 16 字节的二进制字符串，每条记录的开销为2 字节（如果L是字节的长度）值L + 2 字节是磁盘上的大小。）

然后，如果你真的想要优化，可以使用两个表，一个是BLOB，另一个是TINYBLOB（字符串最多2 ^ 8 字节，1 字节开销），然后在VIEW或SELECT期间将它们联合起来。

如果你想进一步优化，可以使用带有BIGINT的第三个表（这将允许存储最多58个位的二进制字符串，因为剩下的6个将需要存储二进制文件的长度字符串）。