Dlaczego Optymalizator zapytań całkowicie ignoruje indeksy widoków indeksowanych?

tl;dr odpowiedź:Jeśli nie określisz NOEXPAND, optymalizator zapytań nie ma pojęcia, że ​​przesyłasz prosty wybór z widoku. Musiałby dopasować rozszerzenie zapytania (czyli wszystko, co widzi) z pewnym indeksem widoku. Prawdopodobnie nie będzie przeszkadzać, gdy jest to połączenie pięciokierunkowe z kilkoma rzutami.

Wyświetlanie dopasowania indeksu do zapytania jest trudnym problemem i uważam, że Twój widok jest zbyt skomplikowany, aby silnik zapytań mógł dopasować go do indeksu. Rozważ to jedno ze swoich pytań:

SELECT ID, Code1 FROM EntityView Where Code1 > 'NR%';

Jest dla Ciebie oczywiste, że można użyć indeksu widoku, ale nie jest to zapytanie, które widzi aparat zapytań. Widoki są automatycznie rozszerzane, jeśli nie określisz NOEXPAND, więc oto, co trafia do silnika zapytań:

SELECT ID, Code1 FROM (
    SELECT e.ID, 'NR'+CAST(c1.CODE as nvarchar(11)) as Code1, 'NR'+CAST(c2.CODE as nvarchar(11)) as Code2, 'NR'+CAST(c3.CODE as nvarchar(11)) as Code3, 'NR'+CAST(c4.CODE as nvarchar(11)) as Code4, 'NR'+CAST(c5.CODE as nvarchar(11)) as Code5
    FROM dbo.Entity e
        inner join  dbo.Classificator1 c1 on e.ID = c1.ID
        inner join  dbo.Classificator2 c2 on e.ID = c2.ID
        inner join  dbo.Classificator3 c3 on e.ID = c3.ID
        inner join  dbo.Classificator4 c4 on e.ID = c4.ID
        inner join  dbo.Classificator5 c5 on e.ID = c5.ID;
) AS V;

Aparat zapytań widzi to skomplikowane zapytanie i zawiera informacje (ale prawdopodobnie nie SQL definicji widoków), które opisują zdefiniowane indeksy widoków. Biorąc pod uwagę, że zarówno to zapytanie, jak i indeksy widoków mają wiele złączeń i rzutowań, dopasowanie jest trudnym zadaniem.

Pamiętaj, że wiesz, że sprzężenia i dopasowania są identyczne w tym zapytaniu i indeksach widoku, ale procesor zapytań o tym nie wie. Traktuje to zapytanie tak samo, jakby łączyło pięć kopii klasyfikatora3 lub jeśli jedną z kolumn było „NQ”+CAST(c2.CODE jako varchar(12)). Program dopasowujący indeks widoków (zakładając, że podjął jakąkolwiek próbę dopasowania tego skomplikowanego zapytania) musiałby dopasować każdy szczegół tego zapytania do szczegółów indeksów widoków w danych tabelach.

Celem nr 1 silnika zapytań jest znalezienie sposobu na wydajne wykonanie zapytania. Prawdopodobnie nie jest przeznaczony do spędzania dużo czasu na próbach dopasowania każdego szczegółu złączenia pięciokierunkowego i CAST do indeksu widoku.

Gdybym miał zgadywać, podejrzewam, że dopasowujący indeks widoku widzi, że kolumny wynikowe zapytania nie są nawet kolumnami żadnej tabeli bazowej (z powodu CAST) i po prostu nie zawraca sobie głowy próbowaniem czegokolwiek. Dodano :Nie mam racji. Właśnie spróbowałem sugestii Martina, aby zaktualizować statystyki, aby zapytanie było drogie, a indeks widoku został dopasowany dla niektórych z tych zapytań bez opcji NOEXPAND. Program dopasowujący widok jest mądrzejszy niż myślałem! Problem polega więc na tym, że program dopasowujący widoki prawdopodobnie bardziej stara się dopasować skomplikowane zapytanie, jeśli jego koszt jest bardzo wysoki.

Użyj wskazówki NOEXPAND zamiast oczekiwać, że aparat zapytań będzie w stanie określić, co pasuje tutaj. NOEXPAND jest absolutnie twoim przyjacielem, ponieważ wtedy silnik zapytań może zobaczyć

SELECT ID, Code1 FROM EntityView Where Code1 > 'NR%';

i dla dopasowującego indeks widoku natychmiast staje się oczywiste, że istnieje przydatny indeks.

(Uwaga:Twój kod SQL Fiddle zawiera wszystkie 5 odniesień do kluczy obcych do tej samej tabeli, co prawdopodobnie nie jest tym, czego chcesz).