6.3.2.2 Чувствительность к регистру

BINARY

Оператор BINARY преобразует следующую за ним строку в строку с двоичными данными. Это простой способ обеспечить сравнение в столбце с учетом регистра, даже если данный столбец не определен как BINARY или BLOB:

mysql> SELECT "a" = "A";
        -> 1

mysql> SELECT BINARY "a" = "A";
        -> 0

BINARY string является сокращением для CAST(string AS BINARY). See section 6.3.5 Функции приведения типов. Оператор BINARY был введен в версии MySQL 3.23.0. Следует учитывать, что при приведении индексированного столбца к типу BINARY MySQL в некоторых случаях не сможет эффективно использовать индексы. Для сравнения двоичных данных типа BLOB без учета регистра данные с типом BLOB перед выполнением сравнения всегда можно конвертировать в верхний регистр:

SELECT 'A' LIKE UPPER(blob_col) FROM table_name;

В скором времени мы планируем ввести преобразование между различными кодировками, чтобы сделать сравнение строк еще более гибким.

User Comments

Experimenting a bit with "column LIKE constant" on an indexed column
shows that it's been optimized as much as one would expect. Thus, having
a constant that starts with a non-wildcard gives you a join type of 'range'.
It's unclear what happens when there's a leading '_' followed by non-wildcards -
will mysql use the sub-ranges for each possible first character, or just search
all rows. The latter is what I'd guess, although I might be wrong.

The new BINARY cast is very useful when you need for different purposes the benefits of both case-independence and case- (and diacritic-) dependence. There seem to be two limitations, though.

There is no symmetric "NATIONAL" cast, so if you are going to sometimes need to do non-BINARY ("NATIONAL") searches, you have to define the field as non-BINARY in the first place and use the BINARY cast when you need it.

Searches using the BINARY cast on a non-BINARY field can also be slow in a big table - presumably because the indexes are non-binary. I can't at the moment see any way of getting the benefit of fast indexed searches in both BINARY and non-BINARY form without duplicating the field.

I needed to put the BINARY keyword after the WHERE
keyword for it to have the desired effect with a
REGEXP operation. Easy to infer, but not exactly
obvious from the example given here.

Add your own comment.