OR / IN
Ich kann das nur erfahrungsgemäß beantworten, da ich nicht mit
FB arbeite. OR macht gerne mal mehrere Scans (also grob für jeden OR Fall)
IN hat natürlich eine andere Funktionalität, die es aber dem Analyzer erlaubt, etwas zielgerichteter zu arbeiten. IN würde aber in Deinem Fall passen.
Letztlich müsstest Du Dir die "Mühe" machen, Ausführungspläne der beiden Varianten zu vergleichen. Ist natürlich statisch dann, die Unterschiede evtl. marginal, aber die Menge machts dann halt.
Ansonsten:
Bei Queries oder auch gerade bei Report Komponenten wird gerne mal ungewollt die Datenmenge ohne Filter geöffnet (wenn mit Filterproperties gearbeitet wird, z.B. sofort bei "Open"). Und bei harmlosen Reports mit einer Untermenge fällt das dann u.U. erst im Produktivbetrieb auf oder wenn dutzende User diese Reports aufrufen.
In der Richtung würde ich mal den Code, das Verhalten untersuchen.
Locate & Co
Denkbar wäre es, alle 4 Mengen vollständig zu öffnen, mittels
Query und gleich richtig sortiert. Dann könnte man Locate oder sogar nur mit Next arbeiten. Könnte schnell sein, würde ich aber als Notlösung sehen.
Wenn Du Dir sicher bist, dass Indizierung und alles andere stimmt, kannst Du auch probehalber 4 Datenquellen mit Datasource und Grids untereinander hängen und mal "sehen", wo die Performance bleibt.
Wenn das flott geht, dann Report Kompos oder deren Verdrahtung genauer anschauen.
Ich würde mit den Ausführungsplänen anfangen. Das ist die Basis und häufig denkt man nicht so, wie der QueryAnalyzer der
DB "denkt".