Wyświetl rozwiązanie

The SQL Server query processor treats indexed and nonindexed views differently:

  • Wiersze widok indeksowany są przechowywane w bazie danych, w tym samym formacie, jako tabela.Jeśli optymalizator kwerendy zdecyduje się użyć planu kwerendy widoku indeksowanego, widok indeksowany jest traktowane w taki sam sposób, jak tabela bazowa.

  • Definicja widoku nieindeksowane jest przechowywana, nie wiersze w widoku.optymalizator kwerendy obejmuje logikę z definicji widoku do planu wykonania buduje instrukcja języka SQL, która odwołuje się do widoku nieindeksowanych.

Logika używana przez SQL Server optymalizator kwerendy, aby zdecydować, kiedy należy używać widok indeksowany jest podobna do logiki, można zdecydować, kiedy należy używać indeksu dla tabela. Jeśli dane w widoku indeksowanym obejmuje całą lub część instrukcja języka SQL i optymalizator kwerendy określa, że indeks w widoku jest ścieżka dostępu tanich, optymalizator kwerendy będzie wybierz indeks, niezależnie od tego, czy widok nie zostanie wywołany przez nazwy w kwerendzie.Aby uzyskać więcej informacji zobaczIndeksy rozpoznawania na widoki.

Po instrukcja języka SQL odwołuje się do widoku nieindeksowanych, analizatora składni i optymalizator kwerendy analizować urządzenie źródłowe instrukcję SQL i widok i rozwiązać je do planu wykonania jednej.Nie ma jeden plan dla instrukcja języka SQL i oddzielne plan dla widoku.

Na przykład rozważmy następujący widok:

USE AdventureWorks;
GO
CREATE VIEW EmployeeName AS
SELECT h.EmployeeID, c.LastName, c.FirstName
FROM HumanResources.Employee AS h 
JOIN Person.Contact AS c
ON h.ContactID = c.ContactID;
GO

W zależności od tego widoku, zarówno te instrukcje SQL wykonywać te same operacje na tabele bazowe i uzyskania takich samych wyniki:

/* SELECT referencing the EmployeeName view. */
SELECT LastName AS EmployeeLastName, SalesOrderID, OrderDate
FROM AdventureWorks.Sales.SalesOrderHeader AS soh
JOIN AdventureWorks.dbo.EmployeeName AS EmpN
ON (soh.ContactID = EmpN.EmployeeID)
WHERE OrderDate > '20020531';

/* SELECT referencing the Contact and Employee tables directly. */
SELECT LastName AS EmployeeLastName, SalesOrderID, OrderDate
FROM AdventureWorks.HumanResources.Employee AS e 
JOIN AdventureWorks.Sales.SalesOrderHeader AS soh
ON soh.SalesPersonID = e.EmployeeID
JOIN AdventureWorks.Person.Contact AS c
ON e.ContactID =c.ContactID
WHERE OrderDate > '20020531';

The SQL Server Management Studio plan wykonania feature shows that the aparat relacyjny builds the same execution plan for both of these SELECT statements.

Wskazówki dotyczące serwerów przy użyciu widoków

Wskazówki, które są umieszczane w widokach w kwerendzie może powodować konflikt z innymi wskazówki, które są wykrywane, gdy widok został rozwinięty w celu dostępu do jego tabel bazowych.W takim wypadku kwerenda zwraca błąd.Na przykład rozważmy następujący widok, który zawiera wskazówkę tabela w definicji:

USE AdventureWorks;
GO
CREATE VIEW Person.AddrState WITH SCHEMABINDING AS
SELECT a.AddressID, a.AddressLine1, 
    s.StateProvinceCode, s.CountryRegionCode
FROM Person.Address a WITH (NOLOCK), Person.StateProvince s
WHERE a.StateProvinceID = s.StateProvinceID;

Teraz załóżmy, że wprowadzenie tej kwerendy:

SELECT AddressID, AddressLine1, StateProvinceCode, CountryRegionCode
FROM Person.AddrState WITH (SERIALIZABLE)
WHERE StateProvinceCode = 'WA';

Kończy się niepowodzeniem, ponieważ wskazówkę dotyczącą SERIALIZABLE, który jest stosowany w widoku Person.AddrState w kwerendzie zostanie przekazane do obu tabel Person.Address i Person.StateProvince w widoku, gdy jest on rozwinięty. Jednak rozwinięciu widoku również ujawnia wskazówka NOLOCK na Person.Address. Ponieważ SERIALIZABLE i NOLOCK pamięci podręcznej wskazówek konfliktu, wynikowa kwerenda jest nieprawidłowa.

PAGLOCK, NOLOCK, ROWLOCK, TABLOCK lub TABLOCKX tabela wskazówki konfliktu ze sobą, tak jak HOLDLOCK, NOLOCK, READCOMMITTED, REPEATABLEREAD, SERIALIZABLE tabela wskazówki.

Wskazówki można propagować za pośrednictwem poziomów zagnieżdżonych widoków.Na przykład załóżmy, że kwerendy wskazówkę dotyczącą HOLDLOCK odnosi się do widoku v1. Kiedy v1 jest rozwinięta, okaże się, że widok v2 stanowi część jego definicję. v2jego definicja zawiera wskazówkę NOLOCK na jednym z jego tabel bazowych.Jednak w tej tabela dziedziczy również wskazówka HOLDLOCK z kwerendy w widoku v1. Ponieważ NOLOCK i HOLDLOCK pamięci podręcznej wskazówek konfliktu, kwerenda nie powiedzie się.

Wskazówka FORCE ORDER użyto w kwerendzie zawierającej widok kolejność łączyć tabel w widoku zależy od pozycji w widoku w uporządkowanej konstrukcji.Na przykład poniższa kwerenda wybiera się z trzech tabel i widoku:

SELECT * FROM Table1, Table2, View1, Table3
WHERE Table1.Col1 = Table2.Col1 
    AND Table2.Col1 = View1.Col1
    AND View1.Col2 = Table3.Col2;
OPTION (FORCE ORDER)

I View1 jest zdefiniowana, jak pokazano poniżej:

CREATE VIEW View1 AS
SELECT Colx, Coly FROM TableA, TableB
WHERE TableA.ColZ = TableB.Colz;

Kolejność łączyć w plan kwerend jest Table1, Table2, TableA, TableB, Table3.