- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Как то давно, для одного из моих сайтов мой тогдашний кодер написал компонент консультаций врачей.
И на странице каждой консультации я попросил выводить рандомно три других, похожих на эту консультацию. Прошли годы, сайт вырос и данный запрос стал подтормаживать. Сам запрос я нашел, но вот часть его логики понять не могу, что собственно и прошу помочь сделать.
Сам запрос:
(SELECT 0 AS level, t1.*, CONCAT_WS('-', t1.id, t1.alias) AS item_alias, CONCAT_WS('-', t2.id, t2.alias) AS section_alias FROM xyfq1_consultations_items AS t1 INNER JOIN xyfq1_consultations_sections AS t2 ON t1.section_id = t2.id WHERE t1.parent_id = 0 AND t1.status = 1 AND t1.id != '1850' AND t1.section_id = '17' AND (t1.name LIKE '%Болезнь%' OR t1.name LIKE '%Паркинсона%')) UNION (SELECT 1 AS level, t1.*, CONCAT_WS('-', t1.id, t1.alias) AS item_alias, CONCAT_WS('-', t2.id, t2.alias) AS section_alias FROM xyfq1_consultations_items AS t1 INNER JOIN xyfq1_consultations_sections AS t2 ON t1.section_id = t2.id WHERE t1.parent_id = 0 AND t1.status = 1 AND t1.id != '1850' AND t1.section_id = '17' AND t1.name NOT LIKE '%Болезнь%' AND t1.name NOT LIKE '%Паркинсона%') ORDER BY RAND() LIMIT 3В функции, формирующей этот запрос такой код
Я так понимаю берется заголовок текущей консультации (какую страницу мы открыли), разбивается по словам и эти слова идут в запрос.
Что я не понимаю - зачем тут UNION ?
Т.е. первую часть запроса я понимаю - он ищет в этой же категории (t1.section_id = '17') консультации, в которых встречаются слова из названия текущей консультации, за исключением самой данной консультации (AND t1.id != '1850'), а далее идет UNION где эти же слова уже в NOT LIKE - ЗАЧЕМ?
Как то давно, для одного из моих сайтов мой тогдашний кодер написал компонент консультаций врачей.
И на странице каждой консультации я попросил выводить рандомно три других, похожих на эту консультацию. Прошли годы, сайт вырос и данный запрос стал подтормаживать. Сам запрос я нашел, но вот часть его логики понять не могу, что собственно и прошу помочь сделать.
Сам запрос:
В функции, формирующей этот запрос такой код
Я так понимаю берется заголовок текущей консультации (какую страницу мы открыли), разбивается по словам и эти слова идут в запрос.
Что я не понимаю - зачем тут UNION ?
Т.е. первую часть запроса я понимаю - он ищет в этой же категории (t1.section_id = '17') консультации, в которых встречаются слова из названия текущей консультации, за исключением самой данной консультации (AND t1.id != '1850'), а далее идет UNION где эти же слова уже в NOT LIKE - ЗАЧЕМ?
Это попытка найти более точные результаты и поxожие
Это попытка найти более точные результаты и поxожие
А в чем логика? Т.е. сначала ищем эти слова, а потом все что не содержит эти слова? Как это поможет повысить точность?
А в чем логика? Т.е. сначала ищем эти слова, а потом все что не содержит эти слова? Как это поможет повысить точность?
В целом, да, так и есть. Логика - дать больше результатов поиска, как вату, если изначальные запросы, к примеру, не дадут достаточный результат
В целом, да, так и есть. Логика - дать больше результатов поиска, как вату, если изначальные запросы, к примеру, не дадут достаточный результат
Все теперь понятно, спасибо. Вероятно это было оправдано в начале, когда консультаций было мало, сейчас их десятки тысяч, уберу Юнион.
далее идет UNION где эти же слова уже в NOT LIKE - ЗАЧЕМ?
Всё же написано: идёт разделение контента на две части - часть, которая содержит определённые слова, идёт в раздел level=0, а часть, которая не содержит этих слов, идёт в раздел level=1.
уберу Юнион
И потеряете level=1. Зачем эта часть нужна - Вам виднее, это надо смотреть, что дальше происходит.
Наверное в плане релевантности лучше использовать полнотекстовый индекс да? И искать нужно не кратком заголовке, а по всему вопросу.
Проверил - по скорости тоже самое что LIKE без Юнион ~0.04 сек
(SELECT 0 AS level, t1.*, CONCAT_WS('-', t1.id, t1.alias) AS item_alias, CONCAT_WS('-', t2.id, t2.alias) AS section_alias
FROM xyfq1_consultations_items AS t1
INNER JOIN xyfq1_consultations_sections AS t2 ON t1.section_id = t2.id
WHERE t1.parent_id = 0 AND t1.status = 1
AND t1.id != '1850'
AND t1.section_id = '17' AND (MATCH(t1.text) AGAINST ('Болезнь') OR MATCH(t1.text) AGAINST ('Паркинсона')))
ORDER BY RAND() LIMIT 3
Скорость это отдельная тема, у тебя мог просто запрос закэшироваться или данных очень мало.
Если хочешь работать с поиском FULLINDEX, то НЕ совмещай в одном запросе выборку и FULLINDEX. БД, по сути, не умеет использовать одновременно два разных типа индексов и поэтому будет страдать скорость в больших масштабах.
Тут ИЛИ сначала делаем выборку по параметрам т.е. используем обычные индексы и уже в полученных данных ищем нужные слова, Или наоборот, ищем нужные слова и кромсаем уже из них.
Конечно можно хрен на это забить, но при масштабировании будет значительная потеря скорости. Но если масштабов не планируется, хотя бы на 2-3ГБ размер текстов, тогда можно и позабить 😊
Это попытка найти более точные результаты и поxожие
Обоснуйте.