- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть примерно такой запрос, упрощённый донельзя
разбиваю на два отдельных и вуаля
(результат 1,2,3,4,5,6...38, подставляю его)
Почему такая разница в скорости?
Прочитайте здесь и здесь. Типа у мускуля головка болит от таких задачек - он их не умеет оптимизировать и вместо оперативной памяти пишет временные таблицы на диск.
Как много результатов во вложенном подзапросе? По something индекс построен?
Были такие же проблемы, в некоторых местах с джойном стало быстрее работать, чем с вложенным селектом.
1) Запросы нужно выполнять с директивой SQL_NO_CACHE
2) Нужно включить профилирование. Скорее всего у вас нет индекса и идет full scan таблицы. При разбиении на отдельные запросы понятно, что полное сканирование не нужно, вы подсовываете константу.
Есть примерно такой запрос, упрощённый донельзя
Не сказали бы что бы так уж "донельзя", попробуйте так
Индексы на table1.id , table2.data_id висят? Поля одинаковые?
разбиваю на два отдельных и вуаля
Версия мускула какая?
Если ниже 5.6, то там была дурацкая бага с вложенными запросами, из-за чего оптимизировать их нормально мускул в большинстве случаев не умел. В 5.6.х (х точно не помним) багу подлечили, в 5.7 вылечили окончательно. Если точнее - в 5.6 и старше мускул приводит подобный вложенный запрос к предложенным нами лефт-джоинам в большинстве случаев.
Не сказали бы что бы так уж "донельзя", попробуйте так
если не ошибаюсь, то запрос можно упростить:
индексы нужны по: table1.id и table2.something
в данном случае индекс по table2.data_id не используется.
А почему все используют LEFT JOIN, а не INNER?
Можно добавить составной индекс на `t2`.`data_id` и `t2`.`something`.
если не ошибаюсь, то запрос можно упростить:
индексы нужны по: table1.id и table2.something
в данном случае индекс по table2.data_id не используется.
Упростить так можно только в случае если data_id только один для каждого id, иначе у Вас будут дубли.
Индекс по table2.data_id нужен что бы объединение таблиц шло по индексам в памяти, а не через построение временных таблиц на диске.
---------- Добавлено 29.11.2016 в 21:06 ----------
А почему все используют LEFT JOIN, а не INNER?
Вообще-то
LEFT JOIN и INNER JOIN - 2 большие разницы.
Плевать какой быстрее. Нужно использовать тот, который по логике возвращает нужные данные.
В данном случае - INNER JOIN.