Oracle что лучше exists или in
Когда мы должны использовать EXISTS , и когда мы должны использовать IN ?
Ключевое слово Exists оценивает значение true или false, но ключевое слово IN сравнивает все значения в соответствующем столбце подзапроса. Еще один Select 1 можно использовать с командой Exists . Пример:
Но IN менее эффективен, поэтому Exists быстрее.
In certain circumstances, it is better to use IN rather than EXISTS. In general, if the selective predicate is in the subquery, then use IN. If the selective predicate is in the parent query, then use EXISTS.
ответ дан Touzene Mohamed Wassim, с репутацией 744, 17.08.2017EXISTS быстрее в производительности, чем IN. Если большинство критериев фильтра находится в подзапросе, то лучше использовать IN, а если большинство критериев фильтра находится в основном запросе, то лучше использовать EXISTS.
EXISTS намного быстрее, чем IN , когда результаты подзапроса очень велики.
IN быстрее, чем EXISTS , когда результаты подзапроса очень малы.
Запрос 1
Запрос 2
Если в t1 ваш идентификатор имеет нулевое значение, тогда Query 1 найдет их, но Query 2 не сможет найти нулевые параметры.
Я имею в виду, что IN не может сравнивать что-либо с нулевым значением, поэтому оно не имеет результата для нулевого значения, но EXISTS может сравнивать все с нулевым значением.
Насколько мне известно, когда подзапрос возвращает значение NULL , тогда весь оператор становится NULL . В этих случаях мы используем ключевое слово EXITS . Если мы хотим сравнить конкретные значения в подзапросах, мы используем ключевое слово IN .
Если вы используете оператор IN, механизм SQL будет сканировать все записи, извлеченные из внутреннего запроса. С другой стороны, если мы используем EXISTS, механизм SQL остановит процесс сканирования, как только найдет совпадение.
Я предполагаю, что вы знаете, что они делают, и, следовательно, используются по-разному, поэтому я пойму ваш вопрос следующим образом: Когда было бы хорошей идеей переписать SQL-код, чтобы использовать IN вместо EXISTS, или наоборот.
Это справедливое предположение?
Редактирование : причина, по которой я спрашиваю, состоит в том, что во многих случаях вы можете переписать SQL на основе IN, чтобы вместо него использовать EXISTS, и наоборот, и для некоторых механизмов баз данных оптимизатор запросов будет обрабатывать их по-разному.
можно переписать на:
или с соединением:
Таким образом, мой вопрос все еще остается в силе, будет хорошей идеей оригинальный постер о том, что делает IN и EXISTS, и, следовательно, как его использовать, или он просит, переписать ли SQL с использованием IN, чтобы использовать вместо EXISTS, или наоборот, будет хорошей идеей ?
Какой из них быстрее, зависит от количества запросов, извлеченных внутренним запросом:
- Когда ваш внутренний запрос извлекает тысячи строк, тогда EXIST будет лучшим выбором.
- Когда ваш внутренний запрос извлекает несколько строк, IN будет быстрее
EXIST оценивается как true или false, но IN сравнивает несколько значений. Если вы не знаете, существует запись или нет, вам следует выбрать EXIST
ответ дан Sumair Hussain Rajput, с репутацией 31, 4.07.2013На основе оптимизатора правил :
- EXISTS намного быстрее, чем IN , когда результаты подзапроса очень велики.
- IN быстрее, чем EXISTS , когда результаты подзапроса очень малы.
На основе оптимизатора затрат :
EXISTS сообщит вам, дал ли запрос какие-либо результаты. е. г. :
IN используется для сравнения одного значения с несколькими и может использовать литеральные значения, например:
Вы также можете использовать результаты запроса с предложением IN , например:
ответ дан Matt Hamilton, с репутацией 159536, 24.08.2008EXISTS - это когда вам нужно сопоставить результаты запроса с другим подзапросом. Результаты запроса № 1 должны быть получены там, где совпадают результаты SubQuery. Вид присоединения. , E. г. выберите таблицу клиентов № 1, которые также разместили таблицу заказов № 2
IN для получения, если значение определенного столбца лежит IN список (1,2,3,4,5) E. г. Выберите клиентов, которые лежат в следующих почтовых индексах i. е. Значения zip_code лежат в (. , , , ) список.
Когда использовать один над другим. , , когда вы чувствуете, что читается соответствующим образом (лучше информирует о намерениях).
Ключевое слово exists можно использовать таким образом, но на самом деле оно предназначено как способ избежать подсчета:
Это наиболее полезно, когда у вас есть if условных операторов, поскольку exists может быть намного быстрее, чем count .
in лучше всего использовать, когда у вас есть статический список для передачи:
Когда у вас есть таблица в выражении in , имеет смысл использовать join , но в основном это не должно иметь значения. Оптимизатор запросов должен возвращать тот же план в любом случае. В некоторых реализациях (в основном старых, таких как Microsoft SQL Server 2000) запросы in всегда будут получать план вложенного объединения , в то время как запросы join будут использовать вложенные значения слияния или хэш в зависимости от ситуации. Более современные реализации умнее и могут корректировать план, даже если используется in .
Насколько я понимаю, оба должны быть одинаковыми, если мы не имеем дело со значениями NULL.
Что касается аргумента «булево против компаратора», то для генерирования логического значения необходимо сравнить оба значения, и это то, что нужно, если работает условие. Так что я не понимаю, как IN и EXISTS ведут себя по-разному ,
Я считаю, что это простой ответ. Почему бы вам не проверить это у людей, которые разработали эту функцию в своих системах?
Если вы являетесь разработчиком MS SQL, вот ответ напрямую от Microsoft.
Определяет, соответствует ли указанное значение какому-либо значению в подзапросе или списке.
Указывает подзапрос для проверки существования строк.
Причина в том, что оператор EXISTS работает по принципу «по крайней мере найден». Возвращает true и останавливает сканирование таблицы, если найдена хотя бы одна подходящая строка.
С другой стороны, когда оператор IN объединяется с подзапросом, MySQL должен сначала обработать подзапрос, а затем использовать результат подзапроса для обработки всего запроса.
Общее правило состоит в том, что если подзапрос содержит большой Объем данных, оператор EXISTS обеспечивает лучшую производительность.
Однако запрос, использующий оператор IN, будет выполняться быстрее, если набор результатов, возвращаемый из подзапроса, очень мал.
Я обнаружил, что использование ключевого слова EXISTS часто очень медленно (это очень верно в Microsoft Access). Вместо этого я использую оператор соединения следующим образом: Если я использую ключевое слово существует в sql
Если подзапрос возвращает более одного значения, вам может потребоваться выполнить внешний запрос - если значения в столбце, указанном в условии, соответствуют любому значению в наборе результатов подзапроса. Для выполнения этой задачи вам нужно использовать ключевое слово in .
Вы можете использовать подзапрос, чтобы проверить, существует ли набор записей. Для этого вам нужно использовать предложение exists с подзапросом. Ключевое слово exists всегда возвращает значение true или false.
Если вы используете оператор IN , механизм SQL будет сканировать все записи, извлеченные из внутреннего запроса. С другой стороны, если мы используем EXISTS , механизм SQL остановит процесс сканирования, как только найдет совпадение.
ответ дан If you are using the IN operat, с репутацией 151, 16.07.2013Разница лежит здесь:
Выше запрос вернет все записи, а ниже один вернет пустой.
Попробуйте и посмотрите на результат.
IN поддерживает только отношения равенства (или неравенство, когда ему предшествует NOT ).
Это синоним = любой / = около , e. г
EXISTS поддерживает варианты типов отношений, которые не могут быть выражены с помощью IN , e. г. -
Предполагаемая производительность и технические различия между EXISTS и в могут быть результатом реализации / ограничений / ошибок конкретного поставщика, но во многих случаях они являются не чем иным, как мифами, созданными из-за непонимания внутренних частей баз данных.
Определение таблиц, точность статистики, конфигурация базы данных и версия оптимизатора оказывают влияние на план выполнения и, следовательно, на показатели производительности.
Поделюсь опытом, который получил за несколько лет оптимизации sql запросов. Большая часть советов касается субд ORACLE.
Если кому статья покажется слишком очевидной, то считайте это заметкой чисто для себя, чтобы не забыть.
1. Ни каких подзапросов, только JOIN
Как я уже писал ранее, если выборка 1 к 1 или надо что-то просуммировать, то ни каких подзапросов, только join.
Стоит заметить, что в большинстве случаев оптимизатор сможет развернуть подзапрос в join, но это может случиться не всегда.
2. Выбор IN или EXISTS ?
На самом деле это сложный выбор и правильное решение можно получить только опытным путем.
Я дам только несколько советов:
* Если в основной выборке много строк, а в подзапросе мало, то ваш выбор IN. Т.к. в этом случае запрос в in выполнится один раз и сразу ограничит большую основную таблицу.
* Если в подзапросе сложный запрос, а в основной выборке относительно мало строк, то ваш выбор EXISTS. В этом случае сложный запрос выполнится не так часто.
* Если и там и там сложно, то это повод изменить логику на джойны.
3. Не забывайте про индексы
Совет для совсем новичков: вешайте индексы на столбцы по которым джойните таблицы.
4. По возможности не используйте OR.
Проведите тесты, возможно UNION выглядит не так элегантно, за то запрос может выполнится значительно быстрей. Причина в том, что в случае OR индексы почти не используются в join.
5. По возможности не используйте WITH в oracle.
Значительно облегчает жизнь, если запрос в with необходимо использовать несколько раз ( с хинтом materialize ) в основной выборке или если число строк в подзапросе не значительно.
Во всех других случаях необходимо использовать прямые подзапросы в from или взаранее подготовленную таблицу с нужными индексами и данными из WITH.
Причина плохой работы WITH в том, что при его джойне не используются ни какие индексы и если данных в нем много, то все встанет. Вторая причина в том, что оптимизатору сложно определить сколько данных нам вернет with и оптимизатор не может построить правильный план запроса.
В большинстве случаев WITH без +materialize все равно будет развернут в основной запрос.
6. Не делайте километровых запросов
Часто в web обратная проблема - это много мелких запросов в цикле и их советуют объединить в один большой. Но тут есть свои ограничения, если у вас запрос множество раз обернутый в from, то внутреннюю(ие) части надо вынести в отдельную выборку, заполнить временную таблицу, навесить индексы, а потом использовать ее в основной выборке. Скорость работы будет значительно выше (в первую очередь из-за сложности построения оптимального плана на большом числе сочетаний таблиц)
7. Используйте KEEP взамен корреляционных подзапросов.
В ORACLE есть очень полезные аналитические функции, которые упростят ваши запросы. Один из них - это KEEP.
KEEP позволит сделать вам сортировку или группировку основной выборки без дополнительно запроса.
Пример: отобрать контрагента для номенклатуры, который раньше остальных был к ней подвязан. У одной номенклатуры может быть несколько поставщиков.
При обычном бы подходе пришлось бы делать корреляционный подзапрос для каждой номенклатуры с выбором минимальной даты.
Но не злоупотребляйте большим числом аналитических функций, особенно если они имеют разные сортировки. Каждая разная сортировка - это новое сканирование окна.
8. Гуляние по выборке вверх-вниз
Менее популярная функция, но не менее полезная. Позволяет смещать текущую строку выборки на N элементов вверх или вниз. Бывает полезно, если необходимо сравнить показатели рядом стоящих строк.
Следующий пример отбирает продажи департаментов отсортированных по дате. К основной выборке добавляются столбцы со следующим и предыдущим значением выручки. Второй параметр - это на сколько строк сместиться, третьи - параметр по-умолчанию, если данные соседа не нашлись. При обычном подходе бы пришлось это делать через логику приложения.
9. Direct Path Read
Установка этой настройки (настройкой или параллельным запросом) - чтение данных напрямую в PGA, минуя буферный кэш. Что укоряет последующие этапы запроса, т.к. не используется UNDO и защелки совместного доступа.
10. Direct IO
Использование прямой записи/чтения с диска без использования буфера файловой системы (файловая система конкретно для СУБД).
* В случае чтения преимущество в использовании буферного кэша БД, замен кэша ФС (кэш бд лучше заточен на работу с sql)
* В случае записи, прямая запись гарантирует, что данные не потеряются в буфере ФС в случае выключения электричества (для redolog всегда использует fsync, в не зависимости от типа ФС)
Это один из наиболее распространенных вопросов, задаваемых разработчиками, которые пишут SQL-запросы к базе данных PostgreSQL. Существует несколько способов, которыми подвыбор или поиск могут быть вставлены в оператор SQL. Оптимизатор PostgreSQL очень умен в оптимизации запросов, и многие запросы могут быть переписаны / преобразованы для повышения производительности.
Давайте обсудим тему с примером, для которого я использую схему, созданную pgbench.
Примечание: для тех, кто не знаком с pgbench, это инструмент для микро-бенчмаркинга, поставляемый с PostgreSQL. Пример схемы pgbench может быть инициализирован с некоторыми данными следующим образом:
Для этого примера я обновил баланс ветвей пары ветвей:
Запросы на включение
Задача SQL для этого примера: узнать количество учетных записей на ветку из pgbench_accounts для тех ветвей, где баланс на уровне филиала больше нуля. Этот запрос может быть написан четырьмя различными способами в соответствии со стандартами ANSI SQL.
1. Использование предложения IN
2. Используя предложение ANY
3. Использование предложения EXISTS
4. Использование INNER JOIN
При написании запроса можно предположить, что EXISTS и INNER JOIN могут быть лучше, потому что они могут использовать всю логику и оптимизацию для объединения двух таблиц, тогда как предложения IN и ANY должны иметь дело с подзапросами. Тем не менее, PostgreSQL (по крайней мере, PG 10 и выше) достаточно умен, чтобы создать один и тот же план выполнения для всех четырех вариантов!
Все вышеперечисленные запросы будут генерировать один и тот же план выполнения следующим образом:
Примечание: Примечание: подавите параллельное выполнение для лучшей читабельности и простого плана выполнения. Даже при параллельном плане выполнения все запросы создают один и тот же план выполнения.
Итак, можем ли мы заключить, что мы можем написать запрос так, как нам удобно, а ум PostgreSQL позаботится обо всем остальном? Подождите! Все может пойти по-другому, если мы возьмем сценарий исключения.
Запросы исключения
Задача SQL выглядит следующим образом : узнать количество учетных записей на ветку из pgbench_accounts EXCEPT для тех ветвей, где баланс на уровне ветви больше нуля.
Таким образом, четыре способа написания запросов становятся:
1. Использование NOT IN
2. Использование <> ALL
3. Использование NOT EXISTS
4. Использование LEFT JOIN и NULL
«NOT IN» и «<> ALL» создают план выполнения с подзапросами (SubPlan). Они соответственно:
Хотя NOT EXISTS и LEFT JOIN создают тот же план выполнения без подплана, как показано ниже:
Эти прямые хэш (анти) объединения между таблицами - самый разумный способ ответить на запрос. Таким образом, это является веской причиной для рекомендации синтаксиса EXISTS или синтаксиса JOIN. Таким образом, общее правило в пользу EXISTS / JOINs остается в силе.
Но подождите! Видим ли мы лучшее время выполнения с предложением NOT IN даже с подпланом? Да. PostgreSQL провел отличную оптимизацию, тем самым подготовив хэш подплана NOT (hashed SubPlan 1) . Таким образом, PostgreSQL лучше понимает, как обращаться с предложением IN, что является логическим способом мышления, поскольку многие люди склонны писать с предложением IN. Но у нас очень мало строк (две), возвращаемых подпланом. То же самое происходит, даже если подзапрос возвращает несколько сотен строк.
Но что, если подзапросом возвращено большое количество строк (несколько сотен тысяч строк)? Давайте попробуем простой пример:
В этом случае план выполнения:
В этом случае план выполнения переключается на материализацию результата подплана, и расчетная стоимость возрастает до 25831564501.02! (При настройках по умолчанию в PostgreSQL, если количество строк из t2 меньше, чем приблизительно 100 КБ, используется хэшированный подплан, как мы уже обсуждали.)
Это приведет к существенному снижению производительности. Таким образом, предложение IN прекрасно работает, если подплан выбирает меньшее количество строк.
Подвох здесь в том, что когда происходит разработка, в таблицах будет меньше строк, и они будут работать по-разному с увеличением количества строк, так как план выполнения смещается и может привести к большим проблемам с производительностью в реальном производстве.
Есть ли еще сложности, о которых мы должны знать?
Да, могут быть преобразования типов данных, когда мы пишем запрос другим способом.
Например, утверждение типа:
приводит к неявному преобразованию типов данных значений полей в текст.
Обратите внимание на преобразование типа данных: ( gen ) :: text . В большой таблице этот тип преобразования будет иметь дополнительные издержки, тогда как PostgreSQL лучше справляется с предложением IN.
Несмотря на то, что предложение IN преобразуется в предложение ANY, преобразование типа данных поля «gen» не выполняется. И указанные значения 'M', 'F' конвертируются в bpchar, который является внутренним эквивалентом CHAR.
Резюме
При написании этого поста я намерен не отдавать предпочтение какому-либо конкретному способу написания запроса, а пролить некоторый свет на то, где что-то может пойти не так и что следует учитывать.
В общем, я привык предлагать разработчикам, что ключ к написанию хорошего оператора SQL - следовать пошаговому процессу.
- Сначала составьте список таблиц, из которых должны быть получены данные.
- Затем подумайте, как присоединиться к этим таблицам.
- Подумайте, как сделать так, чтобы минимальные записи участвовали в условии соединения.
Старайтесь не думать от «Как разбить логику» на подзапросы.
Никогда не предполагайте, что запрос работает хорошо с небольшим количеством данных в таблице.
Используйте план EXPLAIN, чтобы понять, что происходит в фоновом режиме.
В общем случае EXISTS и прямое соединение таблиц часто приводят к хорошим результатам. PostgreSQL во многих случаях оптимизирует предложение IN для хешированного подплана. «IN» может привести к лучшему плану и выполнению в некоторых определенных ситуациях. Опять же, все зависит от того, как запрос переписан / преобразован внутри. Для лучшей оптимизации стоит потратить время на переписывание запросов.
Когда мы должны использовать EXISTS , и когда следует использовать IN ?
ОТВЕТЫ
Ответ 1
Ключевое слово exists может использоваться таким образом, но на самом деле оно предназначено как способ избежать подсчета:
Это наиболее полезно, если у вас есть условные выражения if , поскольку exists может быть намного быстрее, чем count .
in лучше всего использовать, когда у вас есть статический список:
Когда у вас есть таблица в выражении in , имеет смысл использовать join , но в основном это не имеет значения. Оптимизатор запросов должен возвращать тот же план в любом случае. В некоторых реализациях (в основном старше, например Microsoft SQL Server 2000) запросы in всегда будут получать вложенное соединение, а join запросы будет использовать вложенный, merge или хэш, если это необходимо. Более современные реализации умнее и могут корректировать план, даже если используется in .
Ответ 2
EXISTS сообщит вам, возвращает ли запрос какие-либо результаты. например:.
IN используется для сравнения одного значения с несколькими и может использовать литеральные значения, например:
Вы также можете использовать результаты запроса с предложением IN , например:
Ответ 3
На основе оптимизатора правил:
- EXISTS намного быстрее, чем IN , когда результаты подзапроса очень велики.
- IN быстрее, чем EXISTS , когда результаты суб-запроса очень малы.
На основе оптимизатора затрат:
Ответ 4
Я предполагаю, что вы знаете, что они делают, и поэтому используются по-разному, поэтому я буду понимать ваш вопрос так: Когда было бы хорошей идеей переписать SQL для использования IN вместо EXISTS или наоборот наоборот.
Это справедливое предположение?
Изменить. Причина, по которой я спрашиваю, заключается в том, что во многих случаях вы можете переписать SQL на основе IN для использования EXISTS вместо этого, и наоборот, а для некоторых движков базы данных оптимизатор запросов будет обрабатывать два по-разному.
можно переписать на:
или с соединением:
Итак, мой вопрос по-прежнему стоит, является ли исходный плакат вопросом о том, что делает IN и EXISTS, и, следовательно, как его использовать, или он попросит переписать SQL, используя IN для использования EXISTS вместо этого, или наоборот, будет хорошая идея?
Ответ 5
EXISTS намного быстрее, чем IN , когда результаты подзапроса очень велики.
IN быстрее, чем EXISTS , когда результаты подзапроса очень малы.
Запрос 1
Запрос 2
Если в t1 ваш id имеет нулевое значение, то Query 1 найдет их, но Query 2 не сможет найти нулевые параметры.
Я имею в виду, что IN не может сравнивать ничего с NULL, поэтому он не имеет результата для null, но EXISTS может сравнивать все с нулевым.
Ответ 6
Если вы используете оператор IN , механизм SQL будет проверять все записи, извлеченные из внутреннего запроса. С другой стороны, если мы используем EXISTS , механизм SQL остановит процесс сканирования, как только найдет совпадение.
Ответ 7
Ключевое слово Exists оценивает значение true или false, но ключевое слово IN сравнивает все значения в соответствующем столбце подзапроса. Другой Select 1 может использоваться с командой Exists . Пример:
Но IN менее эффективен, поэтому Exists быстрее.
Ответ 8
IN поддерживает только отношения равенства (или неравенство, когда ему предшествует НЕ).
Это синоним = любой/= some, например
EXISTS поддерживает варианты типов отношений, которые не могут быть выражены с помощью IN, например. -
Предполагается, что производительность и технические различия между EXISTS и IN могут возникать из-за конкретных реализаций/ограничений/ошибок поставщика, но во многих случаях это ничего, кроме мифов, созданных из-за отсутствия понимания внутренних систем баз данных.
Определение таблиц, точность статистики, конфигурация базы данных и версия оптимизатора оказывают влияние на план выполнения и, следовательно, на показатели производительности.
Ответ 9
IN следует извлекать, если значение конкретного столбца содержит IN список (1,2,3,4,5) Например. Выберите клиентов, которые находятся в следующих zipcodes, то есть значения zip_code находятся в списке (. ).
Когда использовать один над другим. когда вы чувствуете, что он читает правильно (лучше взаимодействует).
Ответ 10
Выше запроса вернет все записи, а ниже будет возвращено пустое.
Попробуйте и посмотрите результат.
Ответ 11
Как известно, когда подзапрос возвращает значение NULL , весь оператор становится NULL . В этом случае мы используем ключевое слово EXITS . Если мы хотим сравнить определенные значения в подзапросах, то мы используем ключевое слово IN .
Ответ 12
Какой из них быстрее, зависит от количества запросов, полученных внутренним запросом:
- Когда ваш внутренний запрос выбирает тысячи строк, тогда EXIST будет лучшим выбором
- Когда ваш внутренний запрос извлекает несколько строк, тогда IN будет быстрее
EXIST оценивает значение true или false, но IN сравнивает множественное значение. Когда вы не знаете, что запись существует или нет, вы должны выбрать EXIST
Ответ 13
Причина в том, что оператор EXISTS работает на основе принципа "по крайней мере, найденного". Он возвращает true и останавливает таблицу сканирования, если найдена хотя бы одна соответствующая строка.
С другой стороны, когда оператор IN объединен с подзапросом, MySQL сначала обрабатывает подзапрос, а затем использует результат подзапроса для обработки всего запроса.
Общее правило состоит в том, что если в подзапрос содержит большой объем данных, оператор EXISTS обеспечивает лучшую производительность.
Однако запрос, который использует оператор IN, будет работать быстрее, если результирующий набор, возвращенный из подзапроса, очень мал.
Ответ 14
Мое понимание - это то же самое, если мы не имеем дело с значениями NULL.
Как для логического аргумента сравнения или сравнения, для генерации логического значения оба значения нужно сравнивать, и именно так работает любое условие. Поэтому я не понимаю, как IN и EXISTS ведут себя по-разному ,
Ответ 15
Если подзапрос возвращает более одного значения, вам может потребоваться выполнить внешний запрос - если значения в столбце, указанном в условии, соответствуют любому значению в результирующем наборе подзапроса. Для выполнения этой задачи вам нужно использовать ключевое слово in .
Вы можете использовать подзапрос, чтобы проверить, существует ли набор записей. Для этого вам нужно использовать предложение exists с подзапросом. Ключевое слово exists всегда возвращает значение true или false.
Ответ 16
Я считаю, что у этого есть прямой ответ. Почему бы вам не проверить его у людей, которые разработали эту функцию в своих системах?
Если вы разработчик MS SQL, вот ответ от Microsoft.
Определяет, соответствует ли указанное значение любому значению в подзапросе или списке.
Задает подзапрос для проверки существования строк.
Ответ 17
Я обнаружил, что использование ключевого слова EXISTS часто очень медленное (это очень верно в Microsoft Access). Вместо этого я использую оператор объединения таким образом: should-i-use-the-keyword-exists-in-sql
Ответ 18
In certain circumstances, it is better to use IN rather than EXISTS. In general, if the selective predicate is in the subquery, then use IN. If the selective predicate is in the parent query, then use EXISTS.
Ответ 19
EXISTS работает быстрее, чем IN. Если большинство критериев фильтра находится в подзапросе, тогда лучше использовать IN и если большинство критериев фильтра находится в основном запросе, то лучше использовать EXISTS.
Ответ 20
Если вы используете оператор IN, механизм SQL будет сканировать все записи, извлеченные из внутреннего запроса. С другой стороны, если мы используем EXISTS, механизм SQL остановит процесс сканирования, как только найдет совпадение.
Читайте также: