11.4.2. BINARY и VARBINARY Типы

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

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

BINARY и VARBINARY типы данных отличны от CHAR BINARY и VARCHAR BINARY типы данных. Для последних типов, BINARY атрибут не заставляет столбец быть обработанным как столбец двоичной строки. Вместо этого это заставляет двоичное сопоставление для набора символов столбца использоваться, и сам столбец содержит недвоичные символьные строки, а не двоичные строки байтов. Например, CHAR(5) BINARY обрабатывается как CHAR(5) CHARACTER SET latin1 COLLATE latin1_bin, принятие, что набор символов значения по умолчанию latin1. Это отличается от BINARY(5), который хранит 5-байтовые двоичные строки, у которых нет никакого набора символов или сопоставления. Для получения информации о различиях между двоичными сопоставлениями недвоичной строки и двоичными строками, см. Раздел 10.1.7.6," _bin и binary Сопоставления" .

Если строгий режим SQL не включается, и Вы присваиваете значение a BINARY или VARBINARY столбец, который превышает максимальную длину столбца, значение, является усеченным, чтобы соответствовать, и предупреждение сгенерировано. Для случаев усечения можно вызвать ошибку произойти (а не предупреждение) и подавить вставку значения при использовании строгого режима SQL. См. Раздел 5.1.7, "Режимы SQL Сервера".

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

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

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

Для тех случаев, где запаздывающие байты клавиатуры разделяются или сравнения игнорируют их, если у столбца будет индексирование, которое требует уникальных значений, вставляя в значения столбцов, которые отличаются только по числу запаздывающих байтов клавиатуры, то приведет к двойной ключевой ошибке. Например, если таблица содержит '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 типы данных вместо этого.