- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Всем привет.
Есть sql запрос на поиск информации в БД (mySQL)
Поиск идёт всего по ~4000 строкам, но кажется запрос тяжёлый ибо поиск идёт очень долго.
Есть может идеи как можно оптимизировать сие чудо ?
Немного поясню:
IN NATURAL LANGUAGE MODE используется для сортировки по релевантности, так что-бы первыми были те записи, у которых ключ встречается чаще.
А IN BOOLEAN MODE используется ибо требуется только полное совпадение. Т.е. например "ключ" а не "ключица"
А умножение как раз и отсекает такие случаи...
Буду очень благодарен за помощь!! спасибо
inner замените на left, т.к. учитывая having у Вас первая таблица всё равно должна существовать.
having можно спокойно заменить на where, having нужно только при группировке, что бы фильтровать данные после группировки, если группировки нет - он не нужен, а where заведомо быстрее и лучше
country и univerid должны иметь ключи
учитывая что селект Вы полностью не привели - возможно там выбирается туева хуча данных. Если так, то order by может жестко тормозить.
Возможно есть смысл в таком случае сначала выбрать people.id с order by, а потом уже вторым запросом довыбрать все остальное. При этом если country и univerid относятся к таблице people, то в первом запросе джоин вообще не нужен, что опять же изрядно ускорит.
IN BOOLEAN MODE и так не найдет вам ключица если вы ищите ключ
и все ети условые лично для меня полный бред
достаточно MATCH(...) AGAINST ('$search_term_procceded' IN NATURAL LANGUAGE MODE)
оно как раз и выдает по релевантности
тяжелый так как много MATCH(...) AGAINST
хотя 4000 строк ето очень мало. возможно из-за INNER JOIN.
у меня такое было. но у меня было 1500000 строк и один MATCH(...) AGAINST
я разбивал на два запроса
первый MATCH(...) AGAINST собирает айди
а потом кидаем их в нужную таблицу. но ето было в моем случае. у вас видимо етот JOIN нужен.
Спасибо за помощь! Внёс правки согласно рекомендациям.
Заменить having на where не даёт, пишет что нету такой колонки..
А вообще у меня такие чудеса вот.. Похоже самое тяжелое в запросе это вот это первое условие
Если поменять местами первое и второе условие
Скорость возрастает в два раза.
Есть совсем убрать первое условие, то скорость вырастает в три раза.
Если убрать второе условие, эффекта нет.
Заменить having на where не даёт, пишет что нету такой колонки..
Используйте в where не альяс, а оригинал, т.е. матч агаинст вместо скоре.
А вообще у меня такие чудеса вот.. Похоже самое тяжелое в запросе это вот это первое условие
Если поменять местами первое и второе условие
Скорость возрастает в два раза.
Есть совсем убрать первое условие, то скорость вырастает в три раза.
Если убрать второе условие, эффекта нет.
Эксплеин обоих вариантов покажите.
Вместо с1+с2 >0 попробуйте так же c1>0 or c2>0 - возможно будет быстрее, т.к. отрицательных значений там нет, то в данном случае плюс будет эквивалентен or логически.