View Full Version : dynamisches qmqry
Ausserdem ist der "Order by rrn(x)" nicht performanceförderlich.
Ein Like führt immer zum Tablescan wenn es denn keine weiteren Einschränkungen gibt.
vergiss die Verdopplung der Hochkomma nicht, falls Dein String solche enthält.
Ist bekannt, kommt aber nicht vor, BeforeTrigger verhindern das, schon wegen dem csv export.
Ausserdem ist der "Order by rrn(x)" nicht performanceförderlich.
Wenn das PF mit reusedltrcd(*no) erstellt wurde auch?
Ein Like führt immer zum Tablescan wenn es denn keine weiteren Einschränkungen gibt
Ja, stimmt. Daran habe ich bei der Performance-Bemerkung nicht gedacht.
Trotzdem ...
Auch wenn ich in diesem Fall die Unterscheidung GROSS/klein nicht brauche...
Ist das Verhalten 'normal'? einstellbar? oder ein Fehler?
Robi
Wenn das PF mit reusedltrcd(*no) erstellt wurde auch?i
Der Order By wird dabei immer als letztes geprüft!
Sowohl der CQE als auch der SQE-Optimizer versuchen so schnell wie möglich an die Daten zu kommen.
Sofern ein oder mehrere Zugriffsweg verwendet werden können (um möglichst schnell an die Daten zukommen), ist es oft/meist besser diesen zu verwenden, die selektierten Daten temporär (z.B. in Hash-Tables) zu speichern und anschließend das Ergebnis zu sortieren.
Der Table-Scan (bzw. Table-Probe bei SQE) wird durch die Selektion über das LIKE-Prädikat erforderlich, da macht eine anschließende Sortierung des Ergebnisses den Kohl auch nicht mehr allzu fett.
Birgitta
andreaspr@aon.at
16-11-12, 09:01
Ein Like führt immer zum Tablescan wenn es denn keine weiteren Einschränkungen gibt.
Tablescan ja, bei:
WHERE Upper (sp1) like Upper('XXX%')
WHERE sp1 like '%XXX%'
Jedoch bei folgenden Beispiel sollte kein Tablescan durchgeführt werden, falls ein Index mit dem Key vorhanden ist:
WHERE sp1 like 'XXX%'
(Zumindest ab 6.1)
lg Andreas
Dies ist korrekt, manche SQL-Dialekte erlauben da einen "start with ...".