SQL-Abfrage dauert zu lange

[Phoenix]

Sogar Oracle setzt bei sowas einen Full Table Scan an, wenn das Ergebnis noch in der Art wie oben angegeben verjoint wird. Egal, ob da ein Index sitzt oder nicht. Bei so einem geschachtelten Statement setzt früher oder später jede Ablaufplanoptimierung aus, egal wie gut sie ist.

[Masterof]

hallo

ich denke es kommt auf die Anzahl der Datensätze an.
du kannst es ja mal mit den ODBC Treiber für Mysql probieren, vielleicht sind die schneller

[Hoshy]

"OR" Verknüpfungen in Abfragen sind immer schlecht...

Arbeite lieber mir UNION ALL, das dürfte schonmal schneller sein:

SQL-Code:

SELECT kv.*, kr.ID as id_rechnungen, null as id_gutschriften, null as id_lieferscheine
FROM kasse_vorgaenge kv
LEFT JOIN kasse_rechnungen kr ON kv.ID = kr.vorgangsnummer 
WHERE kv.kundennummer = 1 AND kv.datum BETWEEN '2006-05-01' AND '2006-11-28'

UNION ALL

SELECT kv.*, null as id_rechnungen, kg.ID as id_gutschriften, null as id_lieferscheine
FROM kasse_vorgaenge kv
LEFT JOIN kasse_gutschriften kg ON kv.ID = kg.vorgangsnummer 
WHERE kv.kundennummer = 1 AND kv.datum BETWEEN '2006-05-01' AND '2006-11-28'

UNION ALL

SELECT kv.*, null as id_rechnungen, null as id_gutschriften, kl.ID as id_lieferscheine
FROM kasse_vorgaenge kv
LEFT JOIN kasse_lieferscheine kl ON kv.ID = kl.vorgangsnummer 
WHERE kv.kundennummer = 1 AND kv.datum BETWEEN '2006-05-01' AND '2006-11-28'

Leg einen Index über (kv.kundennummer, kv.datum) und jeweils einen über die Vorgangsnummer der anderen Tabellen.

Gruß
Andi

[alzaimar]

Zitat:

Zitat von Phoenix

Sogar Oracle setzt bei sowas einen Full Table Scan an, wenn das Ergebnis noch in der Art wie oben angegeben verjoint wird. Egal, ob da ein Index sitzt oder nicht. Bei so einem geschachtelten Statement setzt früher oder später jede Ablaufplanoptimierung aus, egal wie gut sie ist.

Nee, das kann nicht sein, dann wäre Oracle ja schlechter als mein Frickel-DBMS. Es gibt kein Konstrukt, bei dem ein Optimizer aussetzt und dann nur einen FTS duchführt. Wenn der Optimizer entscheidet, das ein FTS das Billigste ist, dann nur, weil ein Index nicht zur Verfügung steht, oder die Tabellengröße relativ klein ist.

Phoenix, wie kommst Du darauf, das 'selbst Oracle' einen FTS macht... :gruebel:

[Hansa]

Zitat:

Zitat von alzaimar

...Es gibt kein Konstrukt, bei dem ein Optimizer aussetzt und dann nur einen FTS duchführt...

Wie wärs denn hiermit :

SQL-Code:

select * from table where name like '%test%'

? Erkläre mal wie man das optimieren kann. :mrgreen:

[alzaimar]

Hansa, da 'setzt' der Optimierer nicht aus, sondern macht das Beste draus. Kleiner, feiner Unterschied. :mrgreen: Und falls eine Volltextsuche eingeschaltet ist, kann hier auch der dümmste Optimierer optimieren.

[marabu]

Moin Hansa,

das ist einfach: Einen Index auf das Feld legen und aus dem table scan wird ein index scan. Da geht die Post ab - besonders, wenn die index pages auch noch komplett im memory pool des DBMS gehalten werden. Und wenn du das richtige RDBMS verwendest, dann musst du den Index noch nicht mal selbst erzeugen.

Freundliche Grüße

[alzaimar]

Zitat:

Zitat von marabu

Und wenn du das richtige RDBMS verwendest, dann musst du den Index noch nicht mal selbst erzeugen.

Moin marabu,

:shock: Welches RDBMS kann das denn? Welches RDBMS wagt es, meine Indexstrategie zu unterminieren? :zwinker: Her damit!

Grüße.

[Hansa]

Zitat:

Zitat von alzaimar

Welches RDBMS wagt es, meine Indexstrategie zu unterminieren? :zwinker: Her damit!

Wird eine Strategie gebraucht, zusammengesetze Indizes usw. dann wird das wohl nirgends automatisch gehen. Aber das wichtigste müßte die DB schon selber erkennen. Siehe hier :

http://www.ibexpert.info/documentati...dices/419.html

Und das war auch ungefähr das, was ich gemeint hatte. Man könnte ja nun einige Spalten manuell indizieren. Aber die Vorteile werden eben durch Konstrukte wie LIKE %BLUBB% mehr oder weniger zunichte gemacht.

[Union]

Zitat:

Zitat von Hansa

Zitat:

Zitat von alzaimar

...Es gibt kein Konstrukt, bei dem ein Optimizer aussetzt und dann nur einen FTS duchführt...

Wie wärs denn hiermit :

SQL-Code:

select * from table where name like '%test%'

? Erkläre mal wie man das optimieren kann. :mrgreen:

Indem man CONTAINS und FTI einsetzt?