Регистронезависимый поиск в MySQL

Точно не скажу, но. Второй вариант вообще непонятно как к регистронезависимости относится. Первый вариант я бы проверил в лоб - SELECT LOWER('%');

Ну и самый главный вопрос остался за кадром :-) $search - в какой кодировке?

Второй вариант вообще непонятно как к регистронезависимости относится.

UTF8_GENERAL_CI — case insensitive.

Первый вариант я бы проверил в лоб - SELECT LOWER('%');

Запрос работает, но чувствителен к регистру.

$search - в какой кодировке?

UTF-8, инфа 100% :)

В рамках продолжения тупняка и не зная контекста - Замени ' на " :-)

Просто если это консоль, то не ясно само назначение $search.

Это в скрипте. Я пробовал в консольном клиенте набирать

SELECT * FROM TableName WHERE LOWER(`field`) LIKE LOWER('%Текст%');

т.е.

SELECT * FROM TableName WHERE `field` = 'текст';

отрабатывает некорректно? это фантастика же, если гарантированно есть совпадающая запись.

Если упростить, то

SELECT LOWER('Текст') = LOWER('Текст');
-- работает

SELECT LOWER('Текст') = LOWER('текст');
-- не возвращает результат

упрости дальше. убери заветное LOWER. Результат меняется ?

В консоли (на «холостом» запросе) это работает, с реальной таблицей — нет.

А в консоли utf?

Лучше перестрахуйся и проверь, как mysql воспринимает строку:

SELECT COLLATION('%$search%')

Кстати в документации COLLATE ... ставят после аргумента. Может это имеет значение?

Ну, значит, mysql отрабатывает правильно. Проблема в данных. Т.е. при создании базы и таблицы можно указать, конечно utf8_general_ci. И при этом записать туда вполне себе не utf8.

Кстати в документации COLLATE ... ставят после аргумента. Может это имеет значение?

Этот вариант на stackoverflow'е нашел. Пробовал как в документации, все равно не работает. Думаю, что дело в данных, которые берутся из таблицы, но в чем именно, не догоняю.

Лучше перестрахуйся и проверь, как mysql воспринимает строку: SELECT COLLATION('%$search%')

mysql> SELECT COLLATION('%Тест%');
+-------------------------+
| COLLATION('%Тест%') |
+-------------------------+
| utf8_general_ci         |
+-------------------------+
1 row in set (0.00 sec)

Если там не utf8, то как регистрозависимый поиск срабатывает? Уже мозг вывихнул, размышляя об этом.

Это ты в консоли проверял? Там же всё работает - проверь из скрипта.

Ну сам представь. При прямой проверке из консоли, поиск соответствует спецификации. Как только контекст меняется - неправильная выборка. ИМХО проблема в данных, нет пути.

Если из скрипта - не забудь начать сессию set names......

у клиента абсолютно свои понимания :-)

Да. В скрипте проверю завтра на работе, но думаю дело не в подставляемых данных, а в тех, которые берутся [как-то криво] из таблицы.

Тогда ещё проверь, что mysql думает о том, что ты пишешь в базу и кодировку таблиц (вроде она наследуется от базы, но мало ли).

А чем не нравится заюзщать Sphinx или Solr для поиска?

SELECT LOWER('Текст') = LOWER('Текст'); -- работает

SELECT LOWER('Текст') = LOWER('текст'); -- не возвращает результат

mysql> SELECT LOWER('Текст') = LOWER('текст');
+-------------------------------------------+
| LOWER('Текст') = LOWER('текст') |
+-------------------------------------------+
|                                         0 |
+-------------------------------------------+
1 row in set (0.00 sec)

mysql> SET NAMES utf8; 
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT LOWER('Текст') = LOWER('текст');
+-------------------------------------------+
| LOWER('Текст') = LOWER('текст') |
+-------------------------------------------+
|                                         1 |
+-------------------------------------------+
1 row in set (0.00 sec)

CREATE DATABASE DbName CHARACTER SET utf8 COLLATE utf8_general_ci;

Это всё хорошо, а SHOW CREATE TABLE TableName какой чарсет показывает? Для самой таблицы и для title.

Это всё хорошо, а SHOW CREATE TABLE TableName какой чарсет показывает? Для самой таблицы и для title.

mysql> SHOW CREATE TABLE TableName;
... ENGINE=InnoDB DEFAULT CHARSET=utf8 ...

mysql> SHOW FULL COLUMNS FROM TableName;
... utf8_general_ci ...

mysql> SELECT LOWER('Текст') = LOWER('текст');
1 row in set (0.00 sec)

Если вручную вводить текст, то все работает, если брать из таблицы, то нет.

А чем не нравится заюзщать Sphinx или Solr для поиска?

Поделие будет использоваться на дешевых хостингах, где кроме php и mysql ничего не доступно.

LOWER и UPPER разве в mysql уже умеет выполнятся над НЕ ASCII символами??

Это ты в консоли проверял? Там же всё работает - проверь из скрипта.

$sql = "SELECT LOWER(`ТЕКСТ`);";
// текст

$sql = "SELECT LOWER(`title`) FROM TableName WHERE `id` = 1648932;";
// ðºð¾ðºð¾ñ ð¿ñ€ðµð·ðµñ€ð²ð°ñ‚ð¸ð²ñ‹ 

Посмотрите на RLIKE/REGEXP: http://dev.mysql.com/doc/refman/5.1/en/regexp.html

LOWER и UPPER разве в mysql уже умеет выполнятся над НЕ ASCII символами??

Да. =)

Посмотрите на RLIKE/REGEXP: http://dev.mysql.com/doc/refman/5.1/en/regexp.html

Проблема в том, что из таблицы данные берутся испорченными (ðºð¾ðºð¾ñ ð¿ñ€ðµð·ðµñ€ð²ð°ñ‚ð¸ð²ñ‹), регулярки работать тоже не будут.

Если таблица будет больше 100к строк, то надо использовать sphinx или solr.

Иначе каждый такой запрос, полный скан таблицы => большая загрузка CPU => медленное приложение/сайт

Если таблица будет больше 100к строк, то надо использовать sphinx или solr.

Нет возможности.

Иначе каждый такой запрос, полный скан таблицы => большая загрузка CPU => медленное приложение/сайт

Там есть другие ограничивающие условия, которые я не стал приводить, чтобы они не отвлекали внимания.

Вот что нашел. Если не выполнять

$db -> set_charset ('utf8');

����

Нашел источник проблемы. Данные были неизвестным образом изменены при экспорте в mysql дампа postgresql.

SHOW variables like '%char%';

Скорее всего, при заливке дампа во все поля был latin1

Теперь, если не делать client character set utf8, не происходит конвертации latin1 -> utf8

Чтобы всё было правильно надо:

• задампить базу mysqldump, как есть
• Добиться чтобы при подключении mysql в character set во все поля было utf8
• поменять в дампе latin1 на utf8 через sed или perl
• залить дамп

...либо _general_ci (регистронезависимый)