SQL Funktion IN oder OR

[XMan]

Hallo Zusammen,

wollte mal wissen was aus Performance Sicht schneller im SQL ist wenn ich einen Feldinhalt in verschiedensten Sätzen prüfen will.
Ist hier die Funktion IN oder OR schneller?

Beispiel:

select sum(Betrag) into :SumBetrag
from DATEI
where Firma = :A
and Person = :B
and Monat = :Mai
and (FeldA = 'AB' or FeldA = 'CD' or FeldA = 'EF' or FeldA = 'RS' or FeldA = 'UV')

oder

select sum(Betrag) into :SumBetrag
from DATEI
where Firma = :A
and Person = :B
and Monat = :Mai
and FeldA in ('AB', 'CD', 'EF', 'RS', 'UV')

Vielen Dank für Eure Anregungen!

LG

[KingofKning]

Ich sach mal: Versuch macht klug. ___ GG

[andreaspr@aon.at]

Morgen,

Sowas ist etwas schwierig zu beantworten.
Am besten das ganze (wie schon vorgeschlagen) ausführen lassen und die erstellten Zugriffspläne miteinander vergleichen.
Es könnte durchaus sein, dass die DB für beide SQLs den gleichen Zugriffsplan verwendet.

Nur die Zeiten zu messen ist oft trügerisch, da im 1. SQL die Daten der Tabelle in den RAM geschrieben werden und das 2. SQL dadurch schon mal schneller sein kann.

lg Andreas

[B.Hauser]

Lass beide Abfragen durch den Visual Explain laufen.
Visual Explain zeigt den verwendeten Zugriffsplan (Access Plan) an.

Da der Query Optimizer vor Ausführung jedes SQL Statement zunächst scannt und ggf. umschreibt, sollte die Ausführung im Endeffect auf der gleichen (umgeschriebenen) Abfrage basieren und damit auch der gleiche Zugriffsplan verwendet werden.

Auf alle Fälle sollte ein Zugriffsweg (Index oder logische Datei) mit PersNr, Firma, Monat und FeldA vorhanden sein.

ggf. kann man die Performance noch durch einen EVI (Encoded Vector Index) mit den zuvor vorgeschlagenen Schlüssel-Feldern und einer INCLUDE-Anweisung (Sum(Betrag) verbessern.
Wird der EVI verwendet, so kann ein Index-Only-Access (IOA) erfolgen, d.h. alle notwendigen Informationen sind im Index hinterlegt, so dass kein Zugriff auf die eigentlichen Datensätze mehr erforderlich ist.

Birgitta

[XMan]

Vielen Dank für Eure Anregungen!

Ich werde das ganze mal ein wenig testen.
Schöner wäre es gewesen wenn die eine oder andere Methode von Grund her schneller gewesen wäre.
Aber nichts desto trotz ist mir schon sehr viel geholfen.

Danke!
LG

[AG1965_2]

Das wäre dann aber ein mehr als lausiger Optimizer, wenn die eine die andere Methode um Längen schlüge. Die Mehrheit erwartet absolut gleiche Laufzeit.
Aber ich denke, wir sind auch alle gespannt, ob es stimmt. :-)
Bitte berichte!

[B.Hauser]

Schöner wäre es gewesen wenn die eine oder andere Methode von Grund her schneller gewesen wäre.

Warum! Sei doch froh, dass beide Abfragen zum gleichen Access Plan führen!
Es wäre traurig, wenn der Optimizer solche einfachen Dinge nicht erkennen könnte!
Es gibt noch genügend andere Möglichkeiten, bei der die eine oder andere Codierung ein besseres oder schlechters Ergebnis liefern.

Außerdem welchen Sinn macht es ob die eine Version 0,0001 und die andere 0,0002 Sekunden benötigt. Wenn Du nicht die richtigen Zugriffswege hast, bringt das alles nichts.
... und zu glauben, man gibt einfach eine logische Datei an und dann wird diese genommen ...
Pustekuchen! Wenn der Zugriffsweg in der vorgegebenen logischen verwendet wird, ist das nichts weiter als Zufall.

Birgitta

[XMan]

Da es nicht immer nachvollziehbar oder vorhersehbar ist was SQL im Hintergrund genau macht, war für mich auch nicht klar, das selbst unterschiedliche SQL Abfragen (rein von der Codierung her) im Hintergrund für SQL auch gleich sein können.

Nichts desto trotz spielt es für mich insofern eine entscheidende Rolle, da ich nicht nur einen Zugriff in dieser Art pro Person habe sondern viele mehr die mir die Daten sammeln.
Und des weiteren auch das ich sehr viele Personen in der Datenbank habe (bis zu 20000 pro Land).

Aber ich muss mir dazu generell noch Gedanken machen ob ich nicht eine Vorselektion treffen kann der mir den zeitfressenden Zugriff auf die DB minimiert.
Ich komm hier zum Handkuss, den dieses Pgm ist schon älter und ich habs nun "geerbt".

Darum war für mich vorweg ein schneller Ansatz hier zu hinterfragen ob SQL mit der ein oder anderen Methode schneller wäre - ein Trugschluss wie ich feststelle.

Alle Infos die ich bekomme sind für mich hilfreich, auch wenn diese kritisch sind ;-)

Vielen Dank!

[BenderD]

... selbst dieselbe Abfrage könnte in Abhängigkeit von anderen Bedingungen unterschiedlich ausgeführt werden. Beschreibe doch mal genauer Dein Problem (nicht die vermuteten Lösungen), die obige Beschreibung sieht erst mal nicht nach Problem aus: mehrere Zugriffe sind ja normal und 20.000 ist für eine Datenbank nicht viel.

D*B

[andreaspr@aon.at]

Darum war für mich vorweg ein schneller Ansatz hier zu hinterfragen ob SQL mit der ein oder anderen Methode schneller wäre - ein Trugschluss wie ich feststelle.

Grundsätzlich ist dein Ansatz richtig. Bei Probleme mit der Performance sollte neben Indexstrategie auch das SQL selbst kritisch gesehen werden.

[woodstock99]

OPS NAV - PLAN CACHE , Visual Explain , wird SQE verwendet (ok wird bei deinem Statement verwendet (Ausser Omit/Select logische ) aber ich glaub das hat die IBM auch hinbekommen , QAQQINI , Statisik..... das fällt mir auf die schnelle ein