Categories: SQL ServerT-SQL

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:


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:

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!

Fumus

Share
Published by
Fumus

Recent Posts

SQL Server 2019 – static data masking – Du Opfer!

In SQL Server 2016 wurde das sog. dynamic data masking eingeführt. Eine Möglichkeit Daten bei…

5 Jahren ago

MinRole – Oder wie alles etwas einfacher wird

Seit Sharepoint Server 2007 präsentiert sich die Installation immer auf die gleiche Weise. Gerade mal,…

8 Jahren ago

Schritt für Schritt: SQL 2016 – Dynamic Data Masking

Es weihnachtet! Gerade bekam ich von einer Kollegin Plätzchen angeboten mit der Größe eines Diskus…

8 Jahren ago

Schritt für Schritt: SQL Server 2016 – temporal tables

Nein, bitte nicht verwechseln: temporal tables haben nichts zu tun mit temporary tables table variables…

9 Jahren ago

SQL Server 2016 Schritt für Schritt–Installation und First Look

SQL Server 2016.. habe ich schon erwähnt, dass ich den ziemlich cool finde? Wollen wir…

9 Jahren ago

SQL Server 2016 – CTP2

Nach langer Zeit wieder mal eine Artikel von mir.. der mich besonders erfreut. SQL Server…

9 Jahren ago