SQL-Performanceeinbruch bei SELECT

[alzaimar]

Es geht hier doch nicht um Datenmassen, die aggregiert werden müssen, um der Geschäftsleitung die Statistiken der letzten Jahrhunderte so zu präsentieren, das selbst sie es verstehen. Es handelt sich um eine normale Tabelle, bei der einfach nur ein paar Daten zusammengesucht werden.

Was mich immer wieder entäuscht, ist die Tatsache, das ein eigentlich sauberes SQL-Statement aus einem Ferrari einen Eselskarren macht. Die Engine klappert nur ein paar Indexe ab, und müsste die Abfrage eigentlich in wesentlich kürzerer Zeit abarbeiten: Die View an sich ist ja sehr groß, aber die WHERE-Klausel limitiert die zu verknüpfenden Datensätze (aus der [Order]-Tabelle) schon auf das Endresultat. Da hier ein Index ansetzt (sieht man im Execution Plan), müsste die Engine nur die paar 1000 Records abklappern und über die Verknüpfungen die restlichen Daten zusammensuchen. Laut Execution Plan macht sie das auch. Nur eben in 30-40 Sekunden.

Prinzipiell sieht die vom Client generierte Abfrage so aus:

Select [bla] from View_Orders where [Einschränkungen für die Order-Tabelle] and [Einschränkungen der verknüpften Felder] Bei den 'Einschränkungen für die Order-Tabelle' handelt es sich um ein Zeitfenster sowie noch ein paar Dinge ('Alle vermittelten Aufträge von Gestern'), die dann bestimmten Filterkriterien (z.B. Kundenname enthält 'umpitz') entsprechen. Mit diesem Wissen kann ich dann die erwähnte Funktion schreiben, die mir dann die fertige Tabelle zusammenbastelt. Zunächst erstellt sie eine Tabelle, die alle Records mit den 'Einschränkungen für die Order-Tabelle' enhält. Dann wird sie befüllt und abschließend werden die Daten gefiltert.
Befriedigend ist das aber nicht, weil nicht allgemeingültig.

Es ist wirklich bedauerlich, wie schnell man in die Trickkiste greifen muss.

@omata: Mit OLAP habe ich mich noch nie beschäftigt, werde ich mich aber mal schlau machen.

Also nochmals Dank an alle Mitdenkenden: Ich probiere heute noch mal ein paar Tricks aus.