Производительность вариантов использования SQL "EXISTS"

# 3 Должен быть лучшим, так как вам все равно не нужны возвращаемые данные. Добавление полей только добавит дополнительных накладных расходов

EXISTS возвращает не фактические данные логический, поэтому рекомендуется использовать №3.

Это один из тех вопросов, который граничит с развязкой священной войны.

Об этом есть довольно хорошее обсуждение здесь.

Я думаю, что ответ, вероятно, состоит в том, чтобы использовать третий вариант, но увеличение скорости настолько бесконечно мало, что действительно не стоит беспокоиться. Это тот тип запроса, который SQL Server в любом случае может оптимизировать изнутри, поэтому вы можете обнаружить, что все параметры эквивалентны.

По крайней мере, в SQL Server

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

Все трое используют один и тот же план выполнения.

Я всегда использую [Select * From ...], поскольку считаю, что он лучше читается, не подразумевая, что я хочу, чтобы что-то, в частности, было возвращено из подзапроса.

Обновлено: Из комментария Дэйва Коста ... Oracle также использует один и тот же план выполнения для всех трех вариантов

Определенно №1. Это «выглядит» пугающе, но поймите, что оптимизатор будет делать правильные вещи и выражает намерения. Также есть небольшой бонус за опечатку, если кто-то случайно подумает, что СУЩЕСТВУЕТ, но наберет IN. # 2 приемлемо, но не выразительно. Третий вариант воняет, на мой не столь скромный взгляд. Для удобства это слишком близко к словам «если не существует никакой ценности».

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

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

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

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

План выполнения. Узнай это, используй, полюби это

На самом деле, нет никакого способа угадать.

Правда о предложении EXISTS заключается в том, что предложение SELECT не оценивается в предложении EXISTS - вы можете попробовать:

SELECT * 
  FROM tableA 
 WHERE EXISTS (SELECT 1/0 
                 FROM tableB 
                WHERE tableA.x = tableB.y)

... и следует ожидать ошибки деления на ноль, но вы этого не сделаете, потому что она не оценивается. Вот почему я обычно указываю NULL в EXISTS, чтобы продемонстрировать, что SELECT можно игнорировать:

SELECT * 
  FROM tableA 
 WHERE EXISTS (SELECT NULL
                 FROM tableB 
                WHERE tableA.x = tableB.y)

Все, что имеет значение в предложении EXISTS, - это предложения FROM и Beyond - WHERE, GROUP BY, HAVING и т. д.

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

Я понимаю, что это старый пост, но я подумал, что важно внести ясность в Зачем: можно выбрать один формат вместо другого.

Во-первых, как указывали другие, механизм базы данных - это предполагаемый, чтобы игнорировать предложение Select. В каждой версии SQL Server есть / есть, есть в Oracle, есть в MySQL и так далее. За многие-многие месяцы разработки баз данных я встречал только одну СУБД, которая неправильно игнорировала предложение Select: Microsoft Access. В частности, более старые версии MS Access (я не могу говорить о текущих версиях).

До того, как я обнаружил эту «особенность», я использовал Exists( Select *.... Однако я обнаружил, что MS Access будет передавать поток через каждый столбец в подзапросе, а затем отбрасывать их (Select 1/0 также не будет работать). Это убедило меня перейти на Select 1. Если бы даже одна СУБД была тупой, могла бы существовать другая.

Написание Exists( Select 1... столь же предельно ясно передает намерение (откровенно глупо утверждать, что «это слишком близко к утверждению« если «нет значения» »для удобства»). И вероятность того, что СУБД сделает что-то глупое с оператором Select, почти невозможно. Select Null служит той же цели, но просто представляет собой большее количество символов для записи.

Я перешел на Exists( Select 1, чтобы убедиться, что СУБД не может быть дурацкой. Однако это было много месяцев назад, и сегодня я ожидал, что большинство разработчиков ожидают увидеть Exists( Select *, который будет работать точно так же.

Тем не менее, я могу назвать одну вескую причину для отказа от Exists(Select *, даже если ваша СУБД оценивает его правильно. Намного легче найти и уничтожить все случаи использования Select *, если вам не нужно пропускать каждый случай его использования в предложении Exists.

В дополнение к тому, что говорили другие, практика использования SELECT 1 возникла на старом Microsoft SQL Server (до 2005 года) - его оптимизатор запросов был недостаточно умен, чтобы избежать физического извлечения полей из таблицы для SELECT *. Насколько мне известно, ни одна другая СУБД не имеет этого недостатка.

EXISTS проверяет наличие строк, а не то, что в них содержится, поэтому, кроме некоторой причуды оптимизатора, подобной описанной выше, на самом деле не имеет значения, что находится в списке SELECT.

SELECT * кажется самым обычным, но другие тоже приемлемы.