Erstellen Sie einen Index auf SQL-Ansicht mit UNION-Operatoren? Wird dies wirklich die Leistung verbessern?

Question

Ich versuche, einen Index für die folgende Ansicht zu erstellen:

SELECT     'Candidate' AS Source, CandidateID AS SourceId, LastName + ', ' + FirstName AS SourceName
FROM         dbo.Candidates
UNION
SELECT     'Resource' AS Source, ResourceID AS SourceId, LastName + ', ' + FirstName AS SourceName
FROM         dbo.Resources
UNION
SELECT     'Deal' AS Source, DealID AS SourceId, CONVERT(varchar, Number) + '-' + CONVERT(varchar, RevisionNumber) AS SourceName
FROM         dbo.Deals
UNION
SELECT     'Job Order' AS Source, JobOrderID AS SourceId, CustomerNumber AS SourceName
FROM         dbo.JobOrders

Ich erhalte den folgenden Fehler:

Msg 1939, Level 16, State 1, Line 2
Cannot create index on view '_Source' because the view is not schema bound.

Ich habe WITH SCHEMABINDING zu CREATE hinzugefügt und erhalte nun den folgenden Fehler:

Msg 10116, Level 16, State 1, Line 2
Cannot create index on view 'DEALMAKER.dbo._Source' because it contains one or more UNION, INTERSECT, or EXCEPT operators. Consider creating a separate indexed view for each query that is an input to the UNION, INTERSECT, or EXCEPT operators of the original view.

Meine Fragen sind:

Wie würde ich einen Index für diese Ansicht erstellen? Würde das Erstellen separater indizierter Ansichten vraiment arbeiten?

Und schließlich: Bin ich vraiment eine Leistungsverbesserung bei allen Abfragen, die mit dieser Ansicht verknüpft sind, feststellen?

Vielen Dank im Voraus!

Answer 1

Sie können keinen Index für eine Ansicht erstellen, die einen Vereinigungsoperator verwendet. Das lässt sich nicht umgehen, tut mir leid!

Ich könnte mir vorstellen, dass Sie das schon gesehen haben, aber sehen Sie sich das an MSDN-Seite . Er enthält die Anforderungen für indizierte Ansichten und erklärt, was sie sind und wie sie funktionieren.

Ob Sie einen Leistungsvorteil sehen würden, wenn Sie die Ansicht indizieren KÖNNTEN, hängt ganz von der Größe Ihrer Tabellen ab. Ich würde keine Auswirkungen auf die Erstellung separater indizierter Ansichten erwarten, da ich davon ausgehe, dass Ihre Tabellen bereits indiziert sind und Sie keine Verknüpfungen oder Logik in der Ansicht vornehmen.

Answer 2

Warum in aller Welt verwenden Sie UNION?

Mit den Literalen in Ihrem SQL gibt es NULL Chance, dass Sie Duplikate haben werden. Also noch einmal: Warum UNION verwenden?

UNION erzwingt eine eindeutige Verknüpfung und ist kaum langsamer als DISTINCT.

Aber da Sie etwas haben, das so aussieht:

SELECT 'A'
UNION
SELECT 'B'
UNION
SELECT 'C'

Es besteht keine Möglichkeit, dass Sie jemals Duplikate haben werden.

Ändern Sie es in UNION ALL und Ihre Abfrage wird viel schneller ausgeführt.

Dies ist grundlegendes SQL - das Schreiben einer gut abgestimmten Abfrage ist wichtiger als das Erstellen von View-Indizes. Beginnen Sie mit den Grundlagen, verstehen Sie SQL, stimmen Sie Ihre Abfrage ab und machen Sie sich DANN Gedanken darüber, wie Sie Speicherplatz verbrauchen und DML verlangsamen, um die Abfragegeschwindigkeit zu verbessern.

EDITAR:

Die Literale in der Abfrage verhindern Duplikate zwischen Tabellen. Die einzige verbleibende Möglichkeit sind Duplikate innerhalb einer oder mehrerer Tabellen. Da die Spalten wie PKs aussehen und es keine Joins gibt, die zu Duplikaten führen könnten, und da die Tabellen alle wie Nachschlagetabellen aussehen, ist das, was ich gesagt habe, richtig. Wenn diese Annahme nicht zutrifft, müssen Sie Mai haben eine legitime Verwendung von UNION ohne ALL. Ich stelle jedoch fest, dass die Leute in 99 % der Fälle wirklich ALL verwenden wollten, und in unserem Unternehmen ist es Standard, einen Kommentar zu SQL mit nur UNION hinzuzufügen, weil es so oft ein Fehler ist. z. B. UNION - ja, ich brauche eine eindeutige Liste.