SQL: Performance LIKE

[B.Hauser]

Wenn der Index ohne Where-Bedingung wirklich verwendet wurde, könnte es daran liegen, dass alle notwendigen Informationen bereits in den Schlüssel-Werten enthalten sind. Ein Zugriff auf die "restlichen" Daten in der Datei/Tabelle ist somit nicht erforderlich! Das könnte bereits die Ursache für die Verbesserung sein.

Birgitta

[andreaspr@aon.at]

Ich glaub dass der Index nur wegen dem ORDER BY benützt wird. Danach selektiert die DB vom Ergebnis die einzelnen Sätze heraus.

[Fuerchau]

Wenn ein Index für ein Where, Group oder Order-Feld existiert so wird dieser auch verwendet.
Sinn macht also eher ein Index auf das Textfeld mit Upper(), da SQL dann schon mal einen Zugriff spart.

Eine Where-Index mit LIKE macht überhaupt keinen Sinn, da der DROP/CREATE ja auch einen Tabelscan macht, was durch den Select ebenso erfolgt.
Und was passiert, wenn 2 User jeweils was anderes suchen?
Soll der eine dann warten oder nimmt der 2. dem 1. den Index weg?

[martrip]

Verstehe. So langsam kommt Licht in die Sache

Werde einmal einen Index mit upper erstellen lassen und dann die Zugriffszeiten analysieren.

Im besten Fall wäre es gut, wenn beide den selben Index zeitgleich verwenden können.
Sollte das nicht gehen, ist es in diesem Fall nicht so tragisch, denn die Anwendung wird nicht sehr oft-, und von nur maximal 5 Usern, verwendet.

[Fuerchau]

Ich hoffe doch, dass das 32K-Feld als VARLEN definiert ist und Restblanks auch tatsächlich entfernt sind.
Auch das spart Suchzeit, da im Zweifel bei 32K ggf. weniger als 1% tatsächlich belegt ist.
Ein %SCAN (SQL macht da ja nichts anderes) geht nicht über die definierte sondern nur über die gefüllte Länge.

[martrip]

Feld ist als VARLEN(5000) definiert, da die meisten Einträge natürlich deutlich kürzer sind als 32k zeichen.

Habe jetzt einmal einen Index erstellt wo das lower() schon enthalten ist.
Hier werde ich aber noch ein rtrim() hinzu geben.

Ich denke dann sollte der Index seine maximale Wirkung für unsere Zwecke entfalten

[Fuerchau]

Allerdings nur, wenn die where-Klausel zum Index identisch ist.

[martrip]

Ah ok, wollte das eigentlich so machen, rtrim ist hier aber nicht zulässig.

create index stamdat.idx_termknpx on stamdat.termknpx(lower(rtrim(TKNTXT)))

Gut dann muss das lower reichen.

VARLEN ist auf 5000 gesetzt.

Gibt es eine andere Möglichkeit die Blanks direkt in der Datei zu entfernen?

[andreaspr@aon.at]

Update Tab Set spalte = rTrim(Spalte)

lg Andreas

[Fuerchau]

Die Programme, die die Daten erstellen sollten das allerdings auch tun!

[martrip]

Verstehe, werden wir beides noch machen.
Denn Index muss ich dann aber nicht neu erstellen nach dem Update oder?

[Fuerchau]

Ein Index wird parallel gepflegt.