Лучший способ получить более точные результаты в MySQL

Я столкнулся с дилеммой в среде разработки. Это структура из трех таблиц:

  1. Содержимое таблицы (статьи, новости...)
  2. Табличные теги (теги для каждой статьи и новостных записей)
  3. Слова пропуска таблицы (такие слова, как «для», «получить», «до»...)

Основная идея заключается в том, чтобы получить записи контента в соответствии с текстовым поиском. Как?

Сначала удаляем слова из текстового поиска в соответствии с таблицей Skip Words, а затем сопоставляем остальные слова с таблицей тегов. Тем не менее, я хотел бы дать "более умный" результат, т.к.

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

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

Последний шаг показывает эти записи, упорядоченные в соответствии с количеством совпадений слов. Итак, учитывая этот процесс, я подумал об использовании:

  1. Временная таблица для загрузки данных со всех упомянутых шагов
  2. Использование одной хранимой процедуры со всей необходимой логикой

Вышеприведенное сравнение тегов с использованием условия «Нравится» ( and field like "word1%" and field like "word2%" )

Тем не менее, меня беспокоит производительность. Это будет процесс на главной странице веб-сайта, который посещают более 1700 раз в час. Я был бы признателен, если бы вы могли объяснить свой опыт в отношении такого процесса (если он был)? или что, по вашему мнению, было бы лучшим способом реализации с учетом производительности?


mysql search performance procedure temporary
person Andino    schedule 18.03.2020    source источник
comment
1000 посещений в день - это ничто, не волнуйтесь, пока не получите 1000 посещений в минуту   -  person RiggsFolly    schedule 18.03.2020
comment
Это должно быть нормально при использовании подстановочного знака в конце шаблона. Было бы проблемой, если бы это было в начале шаблона. Убедитесь, что столбцы поиска проиндексированы.   -  person The Impaler    schedule 18.03.2020
comment
Извините, я отредактировал это. Сайт получает (в среднем) 1700 посещений в час!   -  person Andino    schedule 19.03.2020

Ответы (1)


arrow_upward
0
arrow_downward

Используйте индекс FULLTEXT. Он охватывает некоторые идеи, которые вы пытаетесь заново изобрести. 1700р/час проблем не будет.

WHERE MATCH(col) AGAINST('join*' IN BOOLEAN MODE)

соответствует присоединению / присоединению / присоединению и объединению.

person Rick James    schedule 22.03.2020
comment
На самом деле FULLTEXT-индекс пришел мне в голову, но, согласно моим исследованиям, этот индекс допускает использование подстановочных знаков, но дело в том, что, например, если я посмотрю «join*», он найдет записи, включающие такие слова, как «joins», «присоединение» и т. д. Но мне нужно наоборот, мне нужен тег joi, чтобы он был доступен для выполнения LIKE -> где присоединяется, как concat (тег,%) ‹- в случае, если пользователь вводит присоединиться, присоединяется или присоединение. Три слова вернут одну и ту же запись, но я думаю, что с FULLINDEX я не могу добиться такого решения. я прав? - person Andino; 26.03.2020
comment
@Andino - я добавил пример "join*" in boolean mode - person Rick James; 26.03.2020
comment
Спасибо за пример @RickJames. А мне нужно как раз обратное. Например, если пользователь вводит соединение, мне нужно сравнить его со столбцом. В проиндексированном столбце мы найдем только joi внутри текста. Итак, есть ли способ, который я могу использовать, например, ПОИСКПОЗ (столбец), но с использованием подстановочного знака, например MATCH(concat(col,"*")) или что-то в этом роде? Это связано с тем, что для меня не работает поиск всех комбинаций соединения и добавление их в столбец с индексом FULLTEXT. - person Andino; 26.03.2020