Полнотекстовый поиск MySQL не соответствует

Моя таблица MySQL не возвращает результаты с запросом MATCH (col) AGAINST ('').

Таблица проста:

id | url | fullTextIndex

И мой запрос

SELECT *, Match(fullTextIndex) AGAINST ("7f7f7f807f8080807f8080807f7f7f807c828888808a86967e8b858d7f89838a76829e958f7badb68084a3a38384899077848b877f799f9c85799fa2827d8c8a ") FROM Pictures;

Последний столбец, совпадение, всегда равен 0. За исключением того, что я точно знаю, что приведенная выше строка содержится дословно в одном из значений.

Что следует отметить:

  • Строка находится только в этой строке (поэтому она находится не более чем в 50% строк, поэтому ее нельзя игнорировать).
  • Это не полное значение
  • Столбец представляет собой столбец bigText
  • Когда я использую INSTR, я получаю значение 1 (что правильно)

Любые идеи, почему этот запрос может не работать?


mysql full-text-search full-text-indexing
person LoveAndCoding    schedule 11.12.2011    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Кажется, существует (настраиваемое) верхнее ограничение на длину слов, рассматриваемых для индексации:

http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_ft_max_word_len

Вы можете проверить текущее значение с помощью SHOW VARIABLES LIKE "ft_max_word_len";

На моем сервере он возвращает 84, а ваша строка имеет длину 128 символов.

Предлагаемое исправление:

  1. Добавьте эту строку в свой файл my.cnf: ft_max_word_len=128 (или любую максимальную длину, которая вам нужна)

  2. Перестройте свои индексы в соответствии с рекомендациями на веб-сайте MySQL: REPAIR TABLE tbl_name QUICK;

person BenMorel    schedule 11.12.2011
comment
Есть ли другое решение, чтобы заставить это работать? Я считаю, что это проблема, но мой хост не позволяет мне изменять эти переменные. :( - person LoveAndCoding; 11.12.2011
comment
Боюсь, что нет: ft_max_word_len не является динамической переменной и поэтому должна быть указана в конфигурации сервера! Может быть, изменение в вашем приложении поможет обойти это ограничение? - person BenMorel; 11.12.2011
comment
К сожалению, это тоже не сработает. Это отпечаток, который мы используем для сравнения изображений, мы не можем уменьшить или разбить его. Мне просто нужно настроить для него другой сервер. Спасибо :) - person LoveAndCoding; 11.12.2011
comment
Похоже, вы не можете увеличить ft_max_word_len выше 84 (serverfault.com/q/339859/91709). По-прежнему отмечен как лучший, но это примечание для всех, кто найдет этот вопрос. - person LoveAndCoding; 11.12.2011
comment
TBH, я бы не стал использовать полнотекстовый индекс для такого сопоставления хэшей, это не то, для чего они были разработаны. Я бы настроил другую таблицу с отношением «один ко многим» к вашей текущей таблице, содержащей индексированное поле BINARY(64) (вы можете вставлять/выбирать записи с UNHEX() и HEX() соответственно) и выполнять поиск в этой отдельной таблице. Поиск будет молниеносным и будет работать без дополнительной настройки! - person BenMorel; 11.12.2011
comment
Настоящая проблема в том, что я буду сопоставлять многие ко многим. Это всего лишь отдельный пример. Мне нужно выполнить сопоставление многих со многими этими строками, заданными и сохраненными в определенном порядке, и я буду искать где-то от 40 до 140+ этих строк в любой момент времени. - person LoveAndCoding; 11.12.2011
comment
Возможно, вы могли бы попробовать что-то вроде SELECT imageId FROM fingerprints WHERE fingerprint IN(?, ?, ?) GROUP BY imageId HAVING COUNT(imageId) = 3 (адаптируя количество элементов к каждому запросу, 3 в этом примере); это вернет идентификаторы изображений, имеющих все эти отпечатки пальцев (не проверено, просто мысль) - person BenMorel; 11.12.2011
comment
Это, вероятно, будет то, что нам нужно сделать, но проблема в том, что мы не получим преимущества векторных расстояний при сопоставлении. Настоящей проблемой становится вставка, так как это может быть либо много запросов, либо длинный запрос. Ах хорошо, спасибо за вашу помощь - person LoveAndCoding; 11.12.2011