Использование логики НЕ по отношению к индексам

12

Согласно книге Microsoft по разработке баз данных, экзамен 70-433: Разработка баз данных Microsoft SQL Server 2008 :

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

Так что я взял , что быть NOT IN, и NOT EXISTSт.д.

Теперь, что касается этого SO вопроса, я думал, что выбранное решение @GBN нарушит приведенное выше утверждение.

Видимо, нет.

Итак, мой вопрос: почему?

sql-server index optimization Стюарт Блэклер
источник

Ответы:

21

  • NOT IN (SELECT ...)и NOT EXISTS (SELECT .. WHERE correlation..)являются "Анти-полу-соединения". То есть распознанные операции на основе множества

  • WHERE NOT (MyColumn = 1) фильтр, который требует просмотра всех строк

Для получения дополнительной информации см .:

Изменить: для полноты

Левые соединения часто работают хуже. См. Http://explainextended.com/2009/09/15/not-in-vs-not-exists-vs-left-join-is-null-sql-server

На этом же сайте отмечается, что в MySQL функция NOT EXISTS не оптимизирована, как в других RDBMS, и лучше LEFT JOIN

В SQL Server я знаю по своему опыту, что LEFT JOIN работает не так, как NOT EXISTS. Вам также часто требуется DISTINCT, чтобы получить те же результаты, что и на другом этапе обработки.

ГБН
источник
0

Я использую суб-выбор для этого:

SELECT m* from Main AS m 
    WHERE m.id NOT IN 
        (SELECT m2.id FROM Main AS m2 
           WHERE m2.id IN (...possibly null/empty list goes here...));

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

sofend
источник