Распространяет ли SQL Server условия WHERE в сложных представлениях?

Question

Я следил за этим вопросом с полным примером на тот случай, если неясно, что я имею в виду под вопросом.

Я сделал представление, объединяющее данные примерно из пяти таблиц.Таблицы содержат огромное количество данных, и запросы выполняются медленно.Мой вопрос заключается в том, что если я сделаю:

SELECT * FROM myView WHERE PersonID = 1000 

, SQL Server «знает, что я имею в виду» и автоматически распространит это условие на базовые объединения в представлении?Так что это не работает для всех , но сводит к минимуму результаты на правильных этапах.Или он будет работать для всего, а затем выполнить WHERE ID = 1000 для полного набора результатов?

---

ПРИМЕР

Чтобы упростить (... надеюсь), чтоЯ имею в виду, вот пример сценария псевдо-TSQL:

TABLE People (
    ID,
    Surname,
    DOB
)
TABLE Activities (
    ID,
    TypeID,
    LocationID,
    Date
)
TABLE PersonActivityInvolvements (
    ID, 
    PersonID, 
    ActivityID
)
TABLE ActivityTypes (
    ID,
    Name
)
TABLE Locations (
    ID,
    Street,
    City
)

Итак, я хочу представление, которое показывает мне все People, любые Activities, в которых они участвовали, ActivityType и Location это произошло.Хотя эта настройка не очень сложна, вы можете заметить, что выполнение может занять очень много времени, если, скажем, существуют десятки тысяч каждой сущности.

Представление может выглядеть примерно так:

SELECT 
    *
FROM 
    People LEFT OUTER JOIN PersonActivityInvolvement PA
    ON People.ID = PA.ID
        INNER JOIN Activity 
        ON PA.ID = Activity.ID
            INNER JOIN ActivityTypes AT
            ON A.TypeID = AT.ID
                INNER JOIN Locations 
                ON A.LocationID = Locations.ID

Итак, если нужно было сделать

SELECT * FROM myView WHERE DOB >= dateAdd(YEAR, -18, getDate())

, будет ли запрос в представлении выполняться для всех или SQL Server будет знать, что он должен применить его к полю People.DOB?

Answer 1

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

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

Answer 2

Это называется предикатным нажатием.

SQL Server, как правило, хорош в этом, хотя есть некоторые конструкции, в которых возникли проблемы (например, см. Заключительную часть этой статьи ).

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

Answer 3

Двигатель будет делать все, что он считает самым быстрым.Если вы проиндексировали это поле, и все ваши ключи JOIN проиндексированы, он может запускать или не запускать этот фильтр первым.

Он может запустить фильтр LAST, если предложение WHERE дороже (т.е. неиндексированный) - таким образом дорогая операция выполняется с наименьшим набором результатов.

Единственный способ узнать наверняка - выполнить запрос и проверить план выполнения ( ACTUAL не оценивается).