Anderer Ansicht sein – die Crux der Sicht

Gerade für Anfänger scheinen Sichten das Maß aller Dinge zu sein. Sichten Editor im SSMS verhilft einem spielend einfach komplexere Joins zusammenzubasteln. Und so werden es mehr und mehr Sichten .. und Sichten greifen auf Sichten zu, die auf Sichten zugreifen , die auf Sichten zugreifen. Sie wissen sicherlich was ich meine. Die Idee ist ja ok: Statt komplexen Statements hat man lieber eine – sagen wir mal –  übersichtlichere Abfrage.

Nun muss man aber zwei Dinge wissen:

  1. Sichten sind nichts anderes als Queries. Per se sind also Sichten weder schneller noch langsamer als das Statement, das dahintersteckt.
  2. Der SQL Server Abfrageoptmierer versucht Statements zu vereinfachen und Abfragen, wie der Name es vermuten läßt, zu optimieren.

Je komplexer also die Sichten werden, desto schwieriger wird es für den Optimierer de Abfragen zu vereinfachen. Schlimm wird das ganze erst, wenn die komplexen Sichten, für rel einfach zu erhaltene Ergebnisse verwendet werden. Ergebnisse, die vielleicht nur eine oder zwei Tabellen benötigen, die Sicht dagegen 4 oder 5 Tabellen bewältigen muss.

Sehen wir uns ein Beispiel an:

create view BestPrId
as
select o.OrderID, o.CustomerID, o.OrderDate, od.ProductID 
    from Orders o
    inner join [Order Details] od on o.orderid = od.OrderID
go 

create view Produkt
as
select Productid, ProductName from products p
GO

create view BestProdukt
as
select bp.CustomerID, bp.OrderDate, bp.ProductID, p.ProductName
 from BestPrId bp inner join Produkt P on bp.ProductID=p.ProductID
GO


select CustomerID, OrderDate from bestprodukt

Beachten Sie die letzte Abfrage auf die Sicht. Eigentlich würden wir nur eine Tabellen benötigen, allerdings ist das dem SQL Server nicht möglich, die nicht nötigen Tabellen zu eliminieren.

Der Plan dazu sieht so aus:

image
Die Statistiken melden:  verstrichene Zeit = 125 ms!!

Man beachte die relativ große Differenz zwischen den tatsächlichen und den geschätzten Zeilen.

Im Vergleich dazu die Abfrage, die nur die notwendige Tabelle verwendet:

select o.CustomerID, o.OrderDate
    from orders o

Der Plan dazu:

image

Die Statistik meldet: 80ms

Sie werden sagen: Ja klar, hätte ich nie so gemacht. Aber in der Praxis werden wir eher selten auf die Schnelle eine so einleuchtende Darstellung wie in diesem Beispiel finden. Dennoch steckt oft genug die gleiche Symptomatik dahinter.  Stützen Sie ihre Arbeit also nicht unbedingt auf komplexe Sichten um sich evtl Arbeit zu sparen, immer wieder Joins schrieben zu müssen. Überprüfen sie daher auch bei Gelegenheit ihre Sichten und vor allem denken sie beim Schreiben von Statements mal an den Optimierer. Der wirds Ihnen danken!

Related posts:

Random Posts

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*
*