長いビットストリングに最も効率的なMySQLデータタイプは何ですか？

Question

私は32768ビットの長いビット列をMySQLテーブルに格納する必要があります。このデータの必要性はいつでも索引付けされる必要はなく、フルテキストで検索される必要もありません。私が正しく読んだら、このサイズは、max_packet_sizeと行サイズ制限@ 65kの両方の範囲内でなければなりません。

理想的には、0b形式で文字列を格納したいのですが、これは必須条件ではありません。ディスク上のデータ/サイズが本質的に1：1になるものはどれも素晴らしいでしょう。

BLOBは、1と0（ '010101010101'）のみからなる文字列が通常のテキストと変わらず、Lバイト+2のコストがかかるため、十分に機能していないようです。BIT（）は完璧です最大64ビットに制限されています。

多くのデータ（90％+）は、符号なしBigint内で十分に表現されますが、残りの10％は論理的に分割するよりも洗練されたソリューションを見つけることを奨励します。残りの10％の行にはBLOBを使用するセカンダリ表など）。

ビット単位の操作を許可する任意のタイプのボーナスが追加されますが、それ以外の場合は、MySQLサーバの外部で簡単に実行できます。

この目的で最も効率的なデータ型は何ですか？

Answer 1

私は主にあなたのアクセスパターンに依存していると言います。各アクセス時にビットストリーム全体を読み書きすることができれば、varbinary（4096）はうまく動作し、コンパクトになります（フィールド全体のオーバーヘッドは2バイトに過ぎません）。このモデルでは、アプリケーション側の1ビットは実際にはデータストレージ内の1ビットで表され、クライアントアプリケーションはビットストリングとして解釈します（ビット単位の操作など）

もう少し最適化するには、BIGINTとvarbinary型（4096）を持つテーブルを想像することができます：二つのフィールドの

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

つだけが指定されたレコードのnullではありません。 bit1がヌルでない場合は、64ビットを格納できます。大きいビットストリングの場合、bit1はnullで、代わりにbit2が使用されます。クライアントアプリケーションは、すべてのビット演算を処理するのに十分スマートでなければなりません（ビット1の符号付き/符号なしの問題に特に注意してください）。

Answer 2

BLOBタイプはあなたが必要とするものだと思います。これは、2^16 バイトまでのバイナリ文字列を表し、レコードごとに2 バイトのオーバーヘッドを有することができる（L値のバイトの長さである場合、L + 2 バイトは、ディスク上のサイズです） 。

その後、あなたは本当に、最適化VIEWで、その後UNIONそれら2つのテーブル、BLOBと1とTINYBLOBと他の（文字列の最大2^8 バイト、1 バイトオーバーヘッド）を、使用したい場合またはSELECTの間。

あなたは、さらに最適化BIGINTで3番目のテーブルを使用する場合（これは、残りの6は、バイナリ文字列の長さを格納するのに必要とされるであろうことから、58 ビットまでのバイナリ文字列を格納できるようになります）。