была ткая тема: http://forum.vingrad.ru/forum/topic-52054/unread-1.html

Что быстрее?

1 cлучай:

    



2 cлучай:

    



а как это в PgSQl

есть база 10гиг DBmail VDSManager 


t1 



t2
ничего нут в индексах

Во-первых, должны быть равнозначны. Проверь генерируемые запросы через EXPLAIN <текст_запроса>.

Во-вторых, почему бы не заменить внешний джойн на внутренний, это проще и понятнее для чтения:

Слово INNER можно опустить, тип джойна внутренний по умолчанию, если не указано иначе.

а почему не inner join?   

на всех программа которых я видел на php+MySQL везде стоит LEFT JOIN иногда WHERE, на Oracle INNER JOIN

INNER JOIN - это тоже самое что срванить и через WHERE, если я правильно понял

тогда переделаю на INNER JOIN

Это сообщение отредактировал(а) gcc - 19.8.2009, 08:39

удалил.

Это сообщение отредактировал(а) DimW - 19.8.2009, 09:31

Совсем не то же самое... вот, например, выдержка из справки по MySQL

Если почитать ещё и посравнивать - выяснится, что LEFT/RIGHT JOIN выполняется как INNER JOIN плюс дополнительные прибабахи. Которые процесс, ясен пень, не ускоряют.

Akina, в выдержке нет ни слова про inner join, а втор спрашивал именно про него:

Вот пусть и работает. Если автору это действительно нужно, он пойдёт на сайт мускула и сам почитает. Или найдёт аналогичный раздел в документации на свою СУБД. Мне оно сто лет не надо...
А если ему влом - может поверить на слово. Или не поверить.

речь не о том кому влом, а кому нет.
речь о том что ваш ответ:


на вопрос:

не верен, так как обрабатываться оптимизатором должен одинаково, исключением может быть только глюкавость самого оптимизатора.

Прочитайте ещё раз. 

абсолютно то же (план исполнения должен быть идентичен), что и

но вовсе не то же самое, что 

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

Так вот именно эту неэквивалентность я и показываю.

создаем таблицы и заполняем их данными(СУБД оракл):


выполняем первый запрос:

смотрим план запроса:


второй запрос:


план:


третий запрос:


план:


из преведенных планов видно что они идентичны. статистику выкладывать не буду, поверьте мне на слово - она тоже совпадает.
не нужно данный пример расценивать как руководство к действию т.к. пример был приведен из конкретной СУБД конкретной версии!

Если не влом - план для последнего запроса, но без where, не затруднит?

если что: Oracle9i Enterprise Edition Release 9.2.0.8.0 

Умный, собака    не все СУБД так умеют.

ага  


я думаю что и на оракле не во всех случаях планы будут такими. 
чесно говоря я и сам до последнего не верил что получится, но должен был проверить. 

это без разницы абсолютно

а если так:

тоже?

забыл сказать, что тестировать нету времени, надо чтобы уже всё завтра или после завтра работало   

(если бы было времято протестировал бы всё)

gcc, для меня всегда LIMIT без ORDER BY был загадкой... пофиг что, лишь бы с ног валило? ... но это так, в качестве оффтопа.

Запрос, кроме корректности и валидности, должен быть ещё и читаем (т.е. сопровождаем). Третий вариант явно не катит, а из двух первых выбирай любой. Индексы в данном случае важнее формы запроса.

PS. Счас вроде в политике развития SQL есть движуха от связи к отбору... 

Я тоже не поверил, перепроверять пришлось  Оракля меня тоже удивил переписав третий запрос на иннер джойн

Не так уж и видно этого из приведенных, ну разве что если уж очень наметанным глазом смотреть. У меня не такой. Я созерцая твой план долго вспоминал, умеет ли оракля фильтр совмещать c NL (как он это делаяет для FTS), а то что NL и NL OUTER это суть разные опарации, вообще для мея открытием стало я полагал что это одна операция, но разные предикаты доступа

Прости уж за буквоедство мне кажется так лучше видно будет
План когда оракля смог одуплить что третий запрос эквивалентен inner:


План, когда мы малость подзапутали ораклю, так чтобы он этого не одуплил:



PS Сорри за оффтоп.

Добавлено @ 16:13

Если так то тоже. Но это плохой тон. Есть критерии объединения, они указываютя в конструкции join есть критерии отбора(фильтра),они указываются в конструкции where. В случае с inner join результаты соединения и филтрации совпадают и предикаты могут быть прописаны как в join кляузе так и в where, однако если критерии объединения спустить в where, то это может проканает как old style join, но описывать фильтр в join это обсфукация в чистом виде.

Это сообщение отредактировал(а) Zloxa - 28.8.2009, 09:05

да, полностию согласен - хотел минимизировать колличество ненужной инфы не в оракловой ветке 
а я вот думаю куда ты запропостился, оракл смакуют, а от тебя ни слова. видимо сезон отпусков. 
вообще твои замечания и уточнения вселяют еще большую уверенность в моих выводах и догадках, СПАСИБО!

Добавлено через 6 минут и 26 секунд

FTS это full table scan?

угу 

ок, понял.