Я могу получить лучшую производительность с помощью СОЕДИНЕНИЯ, или использование СУЩЕСТВУЕТ?

Это зависит.

В конечном счете эти 2 служат совершенно различным целям.

Вы СОЕДИНЯЕТЕ 2 таблицы со связанными с доступом записями. Если Вы не должны получать доступ к данным в связанных записях тогда, у Вас нет потребности присоединиться к ним.

СУЩЕСТВУЕТ, может использоваться, чтобы определить, существует ли маркер в данном наборе данных, но не позволит Вам получать доступ к связанным записям.

Сообщение пример этих 2 методов Вы имеете в виду, и я мог бы быть в состоянии дать Вам лучшее представление.

С Вашими двумя таблицами Institutions и Results, если Вы хотите список учреждений, которые имеют результаты, этот запрос будет самым эффективным:

select Institutions.institution_name 
from Institutions
inner join Results on (Institutions.institution_id = Results.institution_id)

, Если Вы имеете institution_id и просто хотите знать, имеет ли он результаты, использование СУЩЕСТВУЕТ, могло бы быть быстрее:

if exists(select 1 from Results where institution_id = 2)
  print "institution_id 2 has results"
else
  print "institution_id 2 does not have results"

Это зависит от вашего оптимизатора. Я попробовал следующие два в Oracle 10g и 11g. В 10g второй был чуть быстрее. В 11g они были идентичны.

Тем не менее, № 1 на самом деле является злоупотреблением предложением EXISTS. Используйте соединения, чтобы найти совпадения.

select *
from
  table_one t1
where exists (
             select *
             from table_two t2
             where t2.id_field = t1.id_field
             )
order by t1.id_field desc


select t1.*
from 
  table_one t1
 ,table_two t2
where t1.id_field = t2.id_field
order by t1.id_field desc 

Существует ли различие в производительности или нет, необходимо использовать то, что более подходит для цели. Ваша цель состоит в том, чтобы получить список Учреждений (не Результаты - Вам не нужны те дополнительные данные). Так выберите Учреждения, которые не имеют никаких Результатов... перевод - использование СУЩЕСТВУЕТ.

Я сказал бы, что СОЕДИНЕНИЕ медленнее, потому что Ваше выполнение запросов останавливается, как только СУЩЕСТВУЕТ, вызов находит что-то, в то время как СОЕДИНЕНИЕ продолжится до самого конца.

РЕДАКТИРОВАНИЕ: Но это зависит от запроса. Это - что-то, что должно быть оценено в зависимости от конкретного случая.

Вы - использование, СУЩЕСТВУЕТ как часть связанного подзапроса? Если так, соединение почти всегда будет быстрее.

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

На самом деле, из Вашего неопределенного описания проблемы, это звучит мне как НЕ В запросе, самый очевидный способ кодировать его:

SELECT *
  FROM Institutions
  WHERE InstitutionID NOT IN (
     SELECT DISTINCT InstitutionID
       FROM Results
     )

ЛЕВОЕ ВНЕШНЕЕ ОБЪЕДИНЕНИЕ будет иметь тенденцию работать лучше, чем НЕ, СУЩЕСТВУЕТ **, но в Вашем случае Вы хотите сделать, СУЩЕСТВУЕТ, и использование простого ВНУТРЕННЕГО ОБЪЕДИНЕНИЯ точно не копирует, СУЩЕСТВУЕТ поведение. Если у Вас будет несколько Результатов для Учреждения, то делание ВНУТРЕННЕГО ОБЪЕДИНЕНИЯ возвратит несколько строк для того учреждения. Вы могли обойти это при помощи ОТЛИЧНОГО, но тогда СУЩЕСТВОВАНИЕ, вероятно, будет лучше для производительности так или иначе.

** Для не знакомых с этим методом:

SELECT
     MyTable.MyTableID
FROM
     dbo.MyTable T1
LEFT OUTER JOIN dbo.MyOtherTable T2 ON
     T2.MyTableID = T1.MyTableID
WHERE
     T2.MyOtherTableID IS NULL

эквивалентно

SELECT
     MyTable.MyTableID
FROM
     dbo.MyTable T1
WHERE NOT EXISTS (SELECT * FROM MyOtherTable T2 WHERE T2.MyTableID = T1.MyTableID)

предположение, что MyOtherTableID является столбцом NOT NULL. Первый метод обычно работает быстрее, чем НЕ, СУЩЕСТВУЕТ метод все же.

Если ТАБЛИЦА РЕЗУЛЬТАТОВ имеет больше чем одну строку на INSTITUTION, EXISTS() обладает дополнительным преимуществом не требования, чтобы Вы выбрали отличные Учреждения.

Что касается производительности, я видел joins, IN(), and EXISTS() каждый быть самым быстрым во множестве использования. Для нахождения лучшего метода в целях, необходимо протестировать.

Если вы имеете в виду использование левого (или правого) внешнего соединения или подзапроса несуществующего, я вполне уверен, что левое внешнее соединение выигрывает в производительности. Например:

SELECT t1.* FROM table1 t1 LEFT OUTER JOIN table2 t2 ON t1.id = t2.id WHERE t2.id IS NULL

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

Если Вы захотите учреждения, которые не имели результатов, то, 'Где Не Существует', подзапрос будет быстрее, поскольку он остановится, как только он находит единственный результат для тех, которые имеют результаты...

, Если Вы хотите учреждения С результатами, но Вы на самом деле не хотите результаты, то же самое. Используйте, 'Где Существует' подзапрос.. Это остановится, как только это находит единственный результат... Это также гарантирует, что набор результатов будет только иметь одну запись на учреждение, тогда как, если бы у Вас было учреждение с несколькими результатами, с помощью подхода соединения, потребовал бы, чтобы Вы добавили 'отличное' ключевое слово или 'Группу' пунктом для устранения дубликата cartesion строки продукта, которые были бы prodcued от нескольких записей Результата, которые соответствовали к единственному insitution.

при необходимости в Результатах, затем сделайте СОЕДИНЕНИЕ - Внутреннее объединение, если Вы не хотите видеть insitutions без результатов и внешнее объединение, если Вы хотите видеть ВСЕ учреждения, включая тех без Результатов.

В зависимости от оператора статистики и сервера БД это не может иметь никакого значения - тот же оптимизированный план запросов может быть произведен.

существует в основном 3 пути который объединяющие таблицы DBS под капотом:

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

• Слияние - для двух таблиц в том же порядке сортировки. Оба пробегаются в порядке и подходятся, где они соответствуют.

• Хеш - все остальное. Временные таблицы используются для создания соответствий.

При помощи существует, можно эффективно вынудить план запросов сделать вложенный цикл. Это может быть самым быстрым путем, но действительно Вы хотите, чтобы планировщик запроса решил.

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

, Например, если бы [Учреждения] и [Результаты] подобные размеры и оба кластеризируются на InstitutionID, слияние было бы самым быстрым. Если [Результаты] намного больше, чем [Учреждения], вложенный цикл может быть более быстрым.