- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева

В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Как то давно, для одного из моих сайтов мой тогдашний кодер написал компонент консультаций врачей.
И на странице каждой консультации я попросил выводить рандомно три других, похожих на эту консультацию. Прошли годы, сайт вырос и данный запрос стал подтормаживать. Сам запрос я нашел, но вот часть его логики понять не могу, что собственно и прошу помочь сделать.
Сам запрос:
В функции, формирующей этот запрос такой код
Я так понимаю берется заголовок текущей консультации (какую страницу мы открыли), разбивается по словам и эти слова идут в запрос.
Что я не понимаю - зачем тут 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 сек
Скорость это отдельная тема, у тебя мог просто запрос закэшироваться или данных очень мало.
Если хочешь работать с поиском FULLINDEX, то НЕ совмещай в одном запросе выборку и FULLINDEX. БД, по сути, не умеет использовать одновременно два разных типа индексов и поэтому будет страдать скорость в больших масштабах.
Тут ИЛИ сначала делаем выборку по параметрам т.е. используем обычные индексы и уже в полученных данных ищем нужные слова, Или наоборот, ищем нужные слова и кромсаем уже из них.
Конечно можно хрен на это забить, но при масштабировании будет значительная потеря скорости. Но если масштабов не планируется, хотя бы на 2-3ГБ размер текстов, тогда можно и позабить 😊
Это попытка найти более точные результаты и поxожие
Обоснуйте.