Типы BINARY и VARBINARY аналогичны типам CHAR и VARCHAR, за исключением того, что они хранят двоичные строки, а не строки без двоичного представления. То есть, они хранят байтовые строки, а не строковые символы. Это означает, что у них есть binary кодировка символов и сортировка, а сравнение и сортировка основаны на числовых значениях байтов в значениях.

Допустимая максимальная длина для BINARY и VARBINARY такая же, как для CHAR и VARCHAR, за исключением того, что длина для BINARY и VARBINARY измеряется в байтах, а не в символах.

Типы данных BINARY и VARBINARY отличаются от типов данных CHAR BINARY и VARCHAR BINARY. Для последних типов атрибут BINARY не приводит к тому, что столбец обрабатывается как столбец двоичных строк. Вместо этого он вызывает использование двоичной (_bin) сортировки для набора символов столбца (или табличного значения по умолчанию, если набор символов столбца не указан), и сам столбец хранит строки символов без двоичного представления, а не двоичные байтовые строки. Например, если набор символов по умолчанию — utf8mb4, то CHAR(5) BINARY обрабатывается как CHAR(5) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin. Это отличается от BINARY(5), который хранит 5-байтовые двоичные строки, имеющие binary кодировку символов и сортировку. Подробную информацию о различиях между сортировкой binary набора символов binary и сортировками _bin наборов символов без двоичного представления см. в Разделе 12.8.5, «Двоичная сортировка по сравнению с _bin сортировками».

Если режим строгого SQL не включен, и вы присваиваете значение столбцу BINARY или VARBINARY, которое превышает максимальную длину столбца, значение усекается до соответствия длине, и генерируется предупреждение. Чтобы в таких случаях возникло сообщение об ошибке (вместо предупреждения) и подавить вставку значения, используйте режим строгого SQL. См. Раздел 7.1.11, «Серверные режимы SQL».

При хранении значений BINARY они дополняются справа значением заполнения до указанной длины. Значение заполнения — 0x00 (нулевой байт). Значения дополняются справа значением заполнения при вставке, и при извлечении не удаляются trailing байты. Все байты значимы в сравнениях, включая операции ORDER BY и DISTINCT. 0x00 и пробел отличаются в сравнениях, при этом 0x00 сортируется перед пробелом.

Пример: Для столбца BINARY(3), 'a ' становится 'a \0' при вставке. 'a\0' становится 'a\0\0' при вставке. Оба вставленных значения остаются неизменными при извлечении.

Для VARBINARY нет заполнения при вставке и не удаляются trailing байты при извлечении. Все байты значимы в сравнениях, включая операции ORDER BY и DISTINCT. 0x00 и пробел отличаются в сравнениях, при этом 0x00 сортируется перед пробелом.

В тех случаях, когда trailing байты заполнения удаляются или сравнения их игнорируют, если столбец имеет индекс, требующий уникальных значений, вставка значений, отличающихся только количеством trailing байтов заполнения, приводит к ошибке дублирования ключа. Например, если таблица содержит 'a', попытка сохранить 'a\0' приведет к ошибке дублирования ключа.

Следует тщательно учитывать указанные выше особенности заполнения и удаления, если вы планируете использовать тип данных BINARY для хранения двоичных данных, и вам необходимо, чтобы извлечённое значение было точно таким же, как сохранённое значение. Следующий пример демонстрирует, как 0x00-заполнение значений BINARY влияет на сравнения значений столбца:

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.