Müssen Sie FKs in den Clustered-Index von SQL Indexed View aufnehmen?

Ich verwende eine SQL Server-indizierte Ansicht, um die Leistung eines Joins zu verbessern, der eine (sehr) große Tabelle nach einer Kategorie in einer kleinen Tabelle filtert. z.B:

CREATE VIEW BigTableSubset WITH SCHEMABINDING 
AS 
SELECT b.ID, b.SomeValue from BigTable b 
INNER JOIN SmallTable s on (b.CategoryFK = s.CategoryPK) 
where s.Type = 'Blah'

CREATE UNIQUE CLUSTERED INDEX PK_BigTableSubset ON BigTableSubset
(ID) 
INCLUDE (SomeValue)

(BigTable.ID ist die PK auf BigTable)

Die Abfrageleistung wesentlich erhöht wird (da die Teilmenge von BigTable erforderlich ist bereits gespeichert), aber ich bin besorgt um sicherzustellen , dass SQL den Index selbst in optimaler Art und Weise aktualisieren kann , wenn entweder die Quellentabellen aktualisiert wird.

Die Frage ist also: Muss ich SmallTable.CategoryPK in den Clustered-Index der Ansicht aufnehmen, um dies sicherzustellen, oder wird SQL dies automatisch als Teil der Indexstruktur tun? Oder anders ausgedrückt: Wie erkennt SQL, welche Seiten im Index jedes Mal aktualisiert werden müssen, wenn eine Tabelle für die linke Hand (SmallTable) aktualisiert wird, und muss ich etwas tun, um dies zu erleichtern?

SQL Server kann die Indizes der Ansicht immer automatisch aktualisieren, wenn sich die Quelltabelle (n) ändern. Sie müssen nichts extra tun.

Sie können einen Abfrageplan überprüfen, der eine der Quelltabellen ändert. Sie werden feststellen, dass es zusätzliche Operatoren gibt, um die Indizes der Ansicht zu aktualisieren. Auf die gleiche Weise müssen alle anwendbaren nicht gruppierten Indizes für die Quelltabellen aktualisiert werden, wenn sich Daten ändern .

Wenn Sie SmallTable so AKTUALISIEREN, dass eine der Spalten in der Ansicht berührt wird, führt SQL mithilfe von CategoryPK von SmallTable eine Suche durch, um übereinstimmende Zeilen in BigTable zu finden, die jetzt in der Ansicht manifestiert (oder entfernt / geändert) werden müssen. Wenn Sie diese Suche optimieren möchten, benötigen Sie einen Index für BigTable (CategoryFK) INCLUDE (ID, SomeValue). Im Allgemeinen möchten Sie einen Index für BigTable erstellen, als ob die indizierte Ansicht nicht vorhanden wäre und Sie die Definition der Ansicht ausführen, jedoch mit einem zusätzlichen WHERE SmallTable.CategoryPK = 'foo'.

Sie benötigen keine zusätzlichen Indizes für SmallTable, wenn die indizierte Ansicht hinzugefügt wird. Nur die bereits vorhandenen, die Sie zur Optimierung des UPDATE verwendet haben (falls vorhanden), da bei der Erfüllung des UPDATE auf SmallTable allein alle Werte erfasst werden, die später für die Korrektur der Ansicht erforderlich sind.

Sie denken vielleicht: "Wenn ich BigTable mit den richtigen Indizes versehen muss, um die Abfrage überhaupt schnell zu machen, wozu dient dann die indizierte Ansicht?" Nun, es ist ein Kompromiss, und es ist möglicherweise in Ordnung, wenn Updates auf SmallTable langsam sind, wenn sie selten sind und die Indizes auf BigTable aus externen Gründen schlecht sind.