Benötigte Zeit für einen Abfrage

[jobo]

Ein OR Kriterium bedeutet -unter Verwendung von Indizierung- immer, dass die DB >nacheinander< den Surchvorgang für die OR Kriterien durchführen muss.
Hier also:
Suche alle Sätze ~"mit München"
dann
Suche alle Sätze ~"mit Frankfurt"

Angenommen, solche Suchvorgänge dauern immer gleich lang, dann dauert die Suche nach 'München or Frankfurt' doppelt so lange wie die Suche nach nur einem der Orte.
Ist ein weiteres Kriterium im Spiel, kann diese doppelte Suche auf der Teilmenge vorgenommen werden, die sich durch das konstante 2. Kriterium ergibt und die ist mglw so klein, dass es gar nicht auffällt. Das Verhalten hängt dann von der Implementierung des Optimizers ab.

Das oben Genannte gilt nur bedingt oder gar nicht für teil- oder gar nicht indizierte Kriterienfelder bzw. Kriterien, die nicht mittels Index untersucht werden können. Siehe Antwort von Sir Rufo.

Ist bspw. das erste gemeinsame Suchkriterium- hier 4EE- von geringer >Selektivität<, dann ist die sich daraus ergebende Einschränkung so gering, dass ein fehlender Index auf dem 2 Kriterium praktisch einem Full Table Scan gleich kommt.

[Furtbichler]

Zitat von jobo:

Ein OR Kriterium bedeutet -unter Verwendung von Indizierung- immer, dass die DB >nacheinander< den Surchvorgang für die OR Kriterien durchführen muss.

Das ist zu pauschal und stimmt wegen dem 'immer' schon mal nicht immer . Man kann es parallelisieren oder optimierte Suchen nach mehreren Schlüsseln verwenden, die das in einem Durchlauf erledigen. Je nach Anzahl der zu suchenden Werte können unterschiedliche Strategien verwendet werden.

Zitat von dataspider:

Wie man da ersehen kann, arbeitet der Optimizer von Firebird (2.52) hier absolut korrekt.

Finde ich nicht. Andere RDBMS benötigen hier nicht viel länger. Ich habe es gerade mit SQL-Server ausprobiert. Der verwendet unterschiedliche Strategien, je nachdem, ob 1,2 oder mehr Werte per OR verknüpft sind.

[Jasocul]

Gründe für dieses Verhalten kann es mehrere geben. Ich bin kein Firebird-Spezi, aber ein paar Dinge sollten vielleicht mal geprüft werden. Meistens ist ein "OR" für eine DB nicht optimal. Das gilt auch für andere Bedingungen. ">=" ist z.B. besser zu verarbeiten als ">", wenn ein Index auf dem Feld liegt.

Vergleiche die Geschwindigkeit für beide Städte getrennt. Falls dort ein auffälliger Unterschied ist, kann auch eine unterschiedliche Spracheinstellung zwischen Client und Server die Ursache sein (München enthält deutsches Sonderzeichen).

Die Reihenfolge der Bedingungen kann eine Rolle spielen. Einfach mal ausprobieren, ob es was in diesem Fall bringt, diese zu verändern.

Eine Abfrage mit "IN", wie weiter oben schon beschrieben ist manchmal besser zu verarbeiten, als ein "OR".

Manchmal sind 2 Abfragen mit einem "UNION" schneller.

Auf jeden Fall sollte man den Analyse-Plan anschauen. Der gibt schon eine Menge Hinweise, wo die Abfrage ausgebremst wird.

[jobo]

Zitat von Furtbichler:

Das ist zu pauschal und stimmt wegen dem 'immer' schon mal nicht immer .

Furtbichler, danke für Deine Korrektur, zumal Du selbst zuvor von Bug und Schlamperei geschrieben hast.

Sobald ein "intelligenter" Optimizer unter Berücksichtigung von Statistiken arbeitet, ist das Verhalten aus der Ferne schwer zu beurteilen, bzw. vorherzusagen. Ich hab pauschal mal das grundsätzliche Verhalten beschrieben.
Erfahrungsgemäß interessiert es doch keine Sau, wie so etwas im Detail funktioniert, solange es funktioniert. Die Standardlösung ist immer , den fehlenden Index einzubauen und fertig.