В этом разделе представлено несколько запросов, связанных с базой данных Adventureworks вместе с их планами выполнения. Эти примеры демонстрируют уже рассмотренные темы, предоставляя вам возможность увидеть, как оптимизатор запросов работает на практике.
В примере 20.6 вводится новая таблица (newaddresses) в базу данных sample.
Пример 20.6 копирует содержимое таблицы address из схемы Person базы данных Adventureworks в новую таблицу базы данных sample. Это необходимо, потому что первая таблица содержит несколько индексов, которые препятствуют прямому использованию таблицы address из базы данных Adventureworks для демонстрации специфических свойств оптимизатора запросов. Кроме этого, в примере создается индекс для столбца stateProvinceiD этой таблицы.
В примере 20.7 показаны запрос с высокой селективностью и план, который выбирает оптимизатор в данном случае.
Фильтр в примере 20.7 выбирает только одну строку из таблицы new_ addresses. (Общее количество строк в этой таблице 19614.) Поэтому селективность выражения в предложении where является очень высокой (1/19614). В этом случае, как вы можете видеть из результатов примера 20.7, оптимизатором будет использоваться существующий индекс для столбца StateProvincelD.
В примере 20.8 показан тот же запрос, что и в примере 20.8, но с другим фильтром.
Хотя запрос в примере 20.8 отличается от запроса из примера 20.7 только значением в правой части условия в предложении where, но план выполнения, выбранный оптимизатором, отличается значительно. В этом случае существующий индекс не будет использован, потому что селективность фильтра низкая. (Отношение количества строк, удовлетворяющих условию, к общему количеству строк в таблице будет 4564/19614 = 0.23, или 23%.)
В примере 20.9 показано использование кластеризованного индекса.
Запрос из примера 20.9 использует кластеризованный индекс рк_Етр1оуее_ EmployeeiD. Этот кластеризованный индекс неявно создается системой, потому что Столбец EmployeeiD является первичным ключом таблицы Employee.
В примере 20.10 показано использование техники вложенных циклов.
Запрос в примере 20.10 использует метод вложенных циклов, хотя соединяемые столбцы в таблицах являются в то же самое время их первичными ключами. По этой причине кто-то мог ожидать, что будет использован метод слияния соединения. Оптимизатор запросов принимает решение использовать вложенные циклы, потому что здесь существует дополнительный фильтр (е.EmployeeiD = 10), который сокращает результирующий набор этого запроса до одной строки.
Небольшое изменение запроса из примера 20.10 оказывает влияние на выбор оптимизатором другой техники обработки соединения (пример 20.11).
Если вы сравните запросы в примерах 20.10 и 20.11, то вы увидите, что у второго отсутствует условие e.EmpioyeeiD = 10. (Это отличие только в запросах.) По этой причине результирующий набор примера 20.11 содержит 290 строк. Поэтому оптимизатор запросов принимает решение, что в данном случае использование метода слияния соединения имеет преимущества.
В примере 20.12 показано использование техники хеширования соединения.
Хотя оба соединяемых столбца в предложении on являются первичными ключами в каждой таблице (Address и stateProvince), оптимизатор запросов не выбирает метод слияния соединения. Причиной является то, что все (19 614) строки таблицы Address принадлежат результирующему набору. В этом случае использование метода хеширования соединения является более предпочтительным, чем обе другие техники обработки.