BINARY と VARBINARY タイプは、非バイナリ文字列ではなく、バイナリ文字列を含んでいるところ以外で CHAR と VARCHAR に似ています。それは、それらが文字の文字列ではなく、バイトの文字列を含んでいるという事です。これは、それらが文字セットを持たず、ソートと比較は値の中の数値バイトに基づいているという意味です。

許容される最大長は、CHAR と VARCHAR と同様で、BINARY と VARBINARY の長さは文字ではなく長さのバイトであるという事以外、BINARY と VARBINARY と同じです。

BINARY と VARBINARY データタイプは CHAR BINARY と VARCHAR BINARY データタイプとは異なります。後者のタイプは、BINARY 属性によってカラムがバイナリ文字列カラムとして扱われる事はありません。代わりに、利用されるカラム文字セットのバイナリ照合を実行し、そしてそのカラム自体がバイナリバイト文字列ではなく非バイナリ文字の文字列を含みます。例えば、CHAR(5) BINARY は、デフォルト文字セットが latin1 だと仮定して、CHAR(5) CHARACTER SET latin1 COLLATE latin1_bin として扱われます。これは、文字セットや照合を持たない5バイトのバイナリ文字列 BINARY(5) とは異なります。

BINARY 値が格納される時、特定の長さまでパッド値で右側が詰められます。パッド値は 0x00 です。(ゼロバイト)値は挿入時には右側が 0x00 で詰められ、選択時に後続バイトは削除されません。全てのバイトは、ORDER BY と DISTINCT 操作を含め、比較において重要です。0x00 バイトとスペースは、0x00 < スペースとなり、比較において異なります。

例:BINARY(3) カラムでは、挿入時 'a ' は 'a \0' になります。'a\0' は挿入時 'a\0\0' になります。選択時、両方の値は変更されません。

VARBINARY では、挿入時に詰められる事も、選択時にバイトが削除される事もありません。全てのバイトは、ORDER BY と DISTINCT 操作を含め、比較において重要です。0x00 バイトとスペースは、0x00 < スペースとなり、比較において異なります。

後続パッドバイトが剥ぎ取られたり、比較がそれらを無視する場合は、もしカラムが固有の値を要求するインデックスを持っていたら、後続パッドバイトだけが異なるカラム値への挿入は重複キーエラーになります。例えば、もしテーブルが 'a' を含んでいると、'a\0' を格納しようとした時重複キーエラーになります。

もしバイナリデータの格納に BINARY データタイプを利用する予定で、検索した値を格納した値と同一にしたいなら、先行パッドと削除文字を注意深く検討する必要があります。次の例は、BINARY 値の 0x00 パッドがどのようにカラム値比較に影響するか、例を示しています。

mysql> CREATE TABLE t (c BINARY(3));
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO t SET c = 'a';
Query OK, 1 row affected (0.01 sec)

mysql> SELECT HEX(c), c = 'a', c = 'a\0\0' from t;
+--------+---------+-------------+
| HEX(c) | c = 'a' | c = 'a\0\0' |
+--------+---------+-------------+
| 610000 |       0 |           1 |
+--------+---------+-------------+
1 row in set (0.09 sec)

もし検索した値がパッドなしの指定したストレージと同じ値でなければいけないなら、VARBINARY か、BLOB データタイプの1つを代わりに利用するのが好ましいです。