блядь, просто йобаная классика

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

на профильных сайтах в интернетах (С)
Там моя подпись, так чот ищи сам

но в двух словах
классическая ошибка - это фильтрация по "правой" таблице при лефт джойне, которая превращает аутер в иннер. если изначально и нужен был иннер, то в нормальных серверах рояли особо не играет. Если оптимизатор говно - рояль может быть

второй классический случай - использование дистинкта при неправильной работе с мастер-слейв
вместо того чтобы юзать exists (который на самом деле нужен), некто юзает джойн со слейвом, получает мультипликацию хедера, пугается и пиздячит туда дистинкт

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

но если запрос выполняется постоянно и многократно - то тут конечно приходтся смотреть как что писать

штоблядьзанахуй??????

Простите, был напуган.

это бред, сорян. По крайней мере для скуля (судя по темпдб)
Для мелких серверов с хуевым оптмизатором - может быть правдой.

ага, таки скуль

какие дубли получались? когда у тебя на один пост было несколько аттачей?

так вроде и задача была " нужно выводить список вложений" - значит ты мог получить в одной теме несколько постов - если в посте было несколько аттачей

С
На, у тебя отвалилось

ты не "элита", ты говно

это поше или очередное его подрожалово?

хаус? как раз досматриваю 21 серию 8го сезона

завиисит от
в общему случае для скуля (а не мускуля) существуют варианты, когда такая замена влияет на производительность

в случае с мелкими базами (мускул, постгре, мария, фиребёрд, етк) изменеие производительности может быть из-за оптимизатора, когда при преобразовании AST для разных кейсов используются разные "костыльные" ветки оптимизатора.

select a.*
from Table1 a left join table2 b on a=b

vs

select a.*
from Table1 a inner join table2 b on a=b

могут давать разный перформанс при разный случаях

нет и не всегда

нет

очень сильно зависит

а что, и правда надо? это же знания из детского сада

ну ладно, что стар, что мал...

давайте на секундочку представим, что формальная запись запроса и правда отображает тот порядок, в котором "физически" соединятся таблицы при выполнении запроса

тогда для select * from Tab1 left join tab2 on a=b будет один вариант соединения - мы идем по Таб1 и лепим к ней Таб2
а вот для select * from Tab1 left INNER join tab2 on a=b будет уже 2 варианта - идти по таб1 и лепить таб2 - или идти по таб2 и лепить к ней таб1
таким образом "Одинаково в обоих случаях" - немного неправильно.

Второй момент - "лефт выполнятеся быстрее, т.к." - во первых не всегда "больше записей" (и как правило - ровно столько же записей - или даже МЕНЬШЕ)
во вторых (зависит от случая) лефт может (и будет) читать с диска меньше данных для "правой" таблицы - следовательно, сам по себе запро будет выполнятся быстрее
Ну и в некоторых случаях лефт все таки возвращает МЕНЬШЕ записей, чем иннер.

upd поправил второй запрос, скопипастил и не заменил лефт на иннер

йобаный блядь в рот....
"ДАвайте ПРЕДСТАВИМ", для целей демонстрации

нормальный подход, от простого к сложному, от частного к общему

што блядь?
Я могу показать как минимум несколько вариантов - с большими таблицами, с маленькими, с индексами, без индексов и так далее.

"второй вариант" показывает, что план выполнения иннер джойна может варьироваться по последовательности соединений
(лефт тоже может,но для простоты мы это не учитываем)

Очень сильно зависит от.
В некоторых случаях нормальный человек НИКОГДА не будет делать индекс на ФК

к примеру, у нас есть таблица неких фактов/журнал/леджер, который содержит поле... ну, например - "аналитика", которое, разумеется, ссылается на справочник "аналитика". Если ссылается - значит нужен ФК.
Но по этому полю только "дополнительно фильтруют" и никогда не используют это поле для основной фильтрации
Следовательно, это поле индексировать не нужно
Таким образом на большой таблице мы экономим один большой ненужный индекс
И если полей типа "аналитика" несколько - то таким образом мы эконономим несколько раз

так, нахуй
Базя, если ты не в состоянии в собственном топике фильтровать обсосов типа дубль вэ - я не вижу смысла обсуждать тут общаться конструктивно

Я пытался.

Одного достаточно, нет? :)

других особо не встречал, за исключение "отложенных индексов" - в случаях, когда потенциально индекс может пригодится, но пока не нужен - потому его или вообще не создают, либо создают задизейбленным (но это тот еще гемор)

В системах ЕТЛ/ДВХ тоже может быть - но это вариация вышеописанного случая с аналитикой, да и вообще там ФК не делают, ибо нефиг.

что сделать "отдельной таблицей"?

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