НЕ В ПРОТИВ НЕ СУЩЕСТВУЕТ

Какой из этих запросов быстрее?

НЕ СУЩЕСТВУЕТ:

SELECT ProductID, ProductName 
FROM Northwind..Products p
WHERE NOT EXISTS (
    SELECT 1 
    FROM Northwind..[Order Details] od 
    WHERE p.ProductId = od.ProductId)

Или НЕ В:

SELECT ProductID, ProductName 
FROM Northwind..Products p
WHERE p.ProductID NOT IN (
    SELECT ProductID 
    FROM Northwind..[Order Details])

План выполнения запроса говорит, что они оба делают одно и то же. Если это так, то какая форма рекомендуется?

Это основано на базе данных NorthWind.

[Редактировать]

Только что нашел эту полезную статью: http://weblogs.sqlteam.com/mladenp/archive/2007/05/18/60210.aspx

Я думаю, что я буду придерживаться НЕ СУЩЕСТВУЕТ.

Я всегда по умолчанию NOT EXISTS.

Планы выполнения могут быть одинаковыми в данный момент , но если один столбец изменен в будущем , чтобы NULLВЛЯЕТСЯ NOT INверсию нужно будет делать больше работы (даже если нет NULLs не фактически присутствует в данных) и семантика NOT INесли NULLs есть настоящий вряд ли будут те, которые вы хотите в любом случае.

Когда ни Products.ProductIDили [Order Details].ProductIDпозволить NULLВЛЯЮТСЯ NOT INбудет рассматриваться идентично следующего запроса.

SELECT ProductID,
       ProductName
FROM   Products p
WHERE  NOT EXISTS (SELECT *
                   FROM   [Order Details] od
                   WHERE  p.ProductId = od.ProductId) 

Точный план может отличаться, но для моего примера я получаю следующее.

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

/*Not valid syntax but better reflects the plan*/ 
SELECT p.ProductID,
       p.ProductName
FROM   Products p
       LEFT ANTI SEMI JOIN [Order Details] od
         ON p.ProductId = od.ProductId 

Если [Order Details].ProductIDэто NULL-able запрос , то становится

SELECT ProductID,
       ProductName
FROM   Products p
WHERE  NOT EXISTS (SELECT *
                   FROM   [Order Details] od
                   WHERE  p.ProductId = od.ProductId)
       AND NOT EXISTS (SELECT *
                       FROM   [Order Details]
                       WHERE  ProductId IS NULL) 

Причина этого заключается в том, что правильная семантика, если она [Order Details]содержит NULL ProductIds, не должна возвращать результатов. См. Дополнительную анти-полусоединение и катушку с подсчетом строк, чтобы убедиться, что это добавлено в план.

Если Products.ProductIDтакже изменить на NULL-able, то запрос становится

SELECT ProductID,
       ProductName
FROM   Products p
WHERE  NOT EXISTS (SELECT *
                   FROM   [Order Details] od
                   WHERE  p.ProductId = od.ProductId)
       AND NOT EXISTS (SELECT *
                       FROM   [Order Details]
                       WHERE  ProductId IS NULL)
       AND NOT EXISTS (SELECT *
                       FROM   (SELECT TOP 1 *
                               FROM   [Order Details]) S
                       WHERE  p.ProductID IS NULL) 

Причина этого в том, что a NULL Products.ProductIdне должно возвращаться в результатах, кроме случаев, когда NOT INподзапрос вообще не возвращал результатов (т. Е. [Order Details]Таблица пуста). В каком случае это должно быть. В плане для моих образцов данных это реализовано добавлением еще одного анти-полусоединения, как показано ниже.

Эффект этого показан в сообщении в блоге, уже связанном Бакли . В этом примере количество логических операций чтения увеличилось с 400 до 500 000.

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

Однако это не единственно возможный план выполнения для столбца NOT INon NULL-able. Эта статья показывает еще один для запроса к AdventureWorks2008базе данных.

Для столбца NOT INon NOT NULLили NOT EXISTSпротив столбца, обнуляемого или не обнуляемого, он дает следующий план.

Когда столбец меняется на NULL-able, NOT INплан теперь выглядит

Это добавляет дополнительный внутренний оператор соединения к плану. Этот аппарат объясняется здесь . Это все, что нужно для преобразования предыдущего поиска по одному коррелированному индексу Sales.SalesOrderDetail.ProductID = <correlated_product_id>в два поиска по внешней строке. Дополнительный включен WHERE Sales.SalesOrderDetail.ProductID IS NULL.

Так как это находится под анти-полусоединением, если этот возвращает какие-либо строки, второй поиск не произойдет. Однако, если Sales.SalesOrderDetailон не содержит NULL ProductIDs, он удвоит количество требуемых операций поиска.

Также имейте в виду, что NOT IN не эквивалентен NOT EXISTS, когда дело доходит до нуля.

Этот пост объясняет это очень хорошо

http://sqlinthewild.co.za/index.php/2010/02/18/not-exists-vs-not-in/

Когда подзапрос возвращает хотя бы один ноль, NOT IN не будет соответствовать ни одной строке.

Причину этого можно узнать, посмотрев детали того, что на самом деле означает операция NOT IN.

Скажем, в целях иллюстрации, что в таблице 4 строки с именем t, есть столбец ID со значениями 1..4

WHERE SomeValue NOT IN (SELECT AVal FROM t)

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

WHERE SomeValue != (SELECT AVal FROM t WHERE ID=1)
AND SomeValue != (SELECT AVal FROM t WHERE ID=2)
AND SomeValue != (SELECT AVal FROM t WHERE ID=3)
AND SomeValue != (SELECT AVal FROM t WHERE ID=4)

Далее давайте скажем, что AVal равен NULL, где ID = 4. Следовательно, сравнение! = Возвращает НЕИЗВЕСТНО. Логическая таблица истинности для AND гласит, что UNKNOWN и TRUE - UNKNOWN, UNKNOWN и FALSE - FALSE. Нет значения, которое может быть AND'd с НЕИЗВЕСТНЫМ для получения результата ИСТИНА

Следовательно, если какая-либо строка этого подзапроса возвращает NULL, весь оператор NOT IN будет иметь значение FALSE или NULL, и никакие записи не будут возвращены.

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

На самом деле, я считаю, что это будет самым быстрым:

SELECT ProductID, ProductName 
    FROM Northwind..Products p  
          outer join Northwind..[Order Details] od on p.ProductId = od.ProductId)
WHERE od.ProductId is null

У меня есть таблица, которая содержит около 120 000 записей, и мне нужно выбрать только те, которые не существуют (сопоставленные с столбцом varchar) в четырех других таблицах с числом строк приблизительно 1500, 4000, 40000, 200. Все участвующие таблицы имеют уникальный индекс на соответствующей Varcharколонке.

NOT INзаняло около 10 минут, NOT EXISTSзаняло 4 секунды.

У меня есть рекурсивный запрос, который мог иметь какой-то ненастроенный раздел, который мог бы внести вклад в 10 минут, но другой вариант, занимающий 4 секунды, объясняет, по крайней мере мне, что NOT EXISTSэто намного лучше или, по крайней мере, это INи EXISTSне совсем то же самое и всегда стоит проверьте, прежде чем идти вперед с кодом.

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

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

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

Я использовал

SELECT * from TABLE1 WHERE Col1 NOT IN (SELECT Col1 FROM TABLE2)

и обнаружил, что это дает неправильные результаты (Под неправильным я подразумеваю никаких результатов). Как был NULL в TABLE2.Col1.

При изменении запроса на

SELECT * from TABLE1 T1 WHERE NOT EXISTS (SELECT Col1 FROM TABLE2 T2 WHERE T1.Col1 = T2.Col2)

дал мне правильные результаты.

С тех пор я начал использовать NOT EXISTS везде, где.

Они очень похожи, но не совсем одинаковы.

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

Если оптимизатор говорит, что они одинаковы, учитывайте человеческий фактор. Я предпочитаю видеть не существует :)

Это очень хороший вопрос, поэтому я решил написать очень подробную статью на эту тему в своем блоге.

Модель таблицы базы данных

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

studentТаблица является родителем, и student_gradeявляется дочерней таблицей , так как он имеет student_id столбец внешнего ключа , ссылающийся Ид столбец первичного ключа в таблице студента.

student tableСодержит следующие две записи:

| id | first_name | last_name | admission_score |
|----|------------|-----------|-----------------|
| 1  | Alice      | Smith     | 8.95            |
| 2  | Bob        | Johnson   | 8.75            |

И в student_gradeтаблице хранятся оценки, полученные студентами:

| id | class_name | grade | student_id |
|----|------------|-------|------------|
| 1  | Math       | 10    | 1          |
| 2  | Math       | 9.5   | 1          |
| 3  | Math       | 9.75  | 1          |
| 4  | Science    | 9.5   | 1          |
| 5  | Science    | 9     | 1          |
| 6  | Science    | 9.25  | 1          |
| 7  | Math       | 8.5   | 2          |
| 8  | Math       | 9.5   | 2          |
| 9  | Math       | 9     | 2          |
| 10 | Science    | 10    | 2          |
| 11 | Science    | 9.4   | 2          |

SQL СУЩЕСТВУЕТ

Допустим, мы хотим, чтобы все ученики получили 10 баллов по математике.

Если нас интересует только идентификатор студента, мы можем выполнить запрос, подобный следующему:

SELECT
    student_grade.student_id
FROM
    student_grade
WHERE
    student_grade.grade = 10 AND
    student_grade.class_name = 'Math'
ORDER BY
    student_grade.student_id

Но приложение заинтересовано в отображении полного имени, а studentне только идентификатора, поэтому нам также нужна информация из studentтаблицы.

Чтобы отфильтровать studentзаписи, которые имеют 10 баллов по математике, мы можем использовать оператор EXISTS SQL, например:

SELECT
    id, first_name, last_name
FROM
    student
WHERE EXISTS (
    SELECT 1
    FROM
        student_grade
    WHERE
        student_grade.student_id = student.id AND
        student_grade.grade = 10 AND
        student_grade.class_name = 'Math'
)
ORDER BY id

При выполнении запроса выше, мы видим, что выбрана только строка Алиса:

| id | first_name | last_name |
|----|------------|-----------|
| 1  | Alice      | Smith     |

Внешний запрос выбирает studentстолбцы строк, которые мы хотим вернуть клиенту. Однако в предложении WHERE используется оператор EXISTS со связанным внутренним подзапросом.

Оператор EXISTS возвращает true, если подзапрос возвращает хотя бы одну запись, и false, если строка не выбрана. Механизм базы данных не должен полностью выполнять подзапрос. Если сопоставляется одна запись, оператор EXISTS возвращает true и выбирается связанная строка запроса.

Внутренний подзапрос коррелируется, потому что столбец student_id student_gradeтаблицы сопоставляется со столбцом id внешней таблицы студентов.

SQL НЕ СУЩЕСТВУЕТ

Давайте рассмотрим, что мы хотим выбрать всех учеников, у которых оценка не ниже 9. Для этого мы можем использовать NOT EXISTS, что сводит на нет логику оператора EXISTS.

Следовательно, оператор NOT EXISTS возвращает true, если базовый подзапрос не возвращает запись. Однако, если внутреннему подзапросу соответствует одна запись, оператор NOT EXISTS вернет false, и выполнение подзапроса может быть остановлено.

Чтобы сопоставить все записи учеников, у которых нет связанных student_grade со значением ниже 9, мы можем выполнить следующий запрос SQL:

SELECT
    id, first_name, last_name
FROM
    student
WHERE NOT EXISTS (
    SELECT 1
    FROM
        student_grade
    WHERE
        student_grade.student_id = student.id AND
        student_grade.grade < 9
)
ORDER BY id

При выполнении запроса выше мы видим, что сопоставляется только запись Алисы:

| id | first_name | last_name |
|----|------------|-----------|
| 1  | Alice      | Smith     |

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

Это зависит..

SELECT x.col
FROM big_table x
WHERE x.key IN( SELECT key FROM really_big_table );

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

Но, в зависимости от оптимизатора СУБД, это может быть не иначе.

Как пример того, когда EXISTS лучше

SELECT x.col
FROM big_table x
WHERE EXISTS( SELECT key FROM really_big_table WHERE key = x.key);
  AND id = very_limiting_criteria