SQL: Performance LIKE

[andreaspr@aon.at]

Der neue Index beinhaltet nur jene Sätze wo der entsprechende Wert in der Spalte vorhanden ist.
Alle anderen Sätze fallen weg.

Dadurch hat der Index nur eine geringere Anzahl von Sätzen.

Durch die WHERE-Bedingung "SP like '%...%'" im SELECT wird automatisch der neue Index benützt und der Teil "SP like '%...%'" fällt einfach weg.

Kurz gesagt, ersparrt sich die DB alle Sätze mit dem Schlüsselwort LIKE zu durchsuchen da im Index schon alle Sätze beinhaltet.

lg Andreas

[Pikachu]

Der Index wurde anscheinend aber ohne die Bedingung erstellt.

[martrip]

Danke für die Erklärung Andreas.

Ich poste mal genau, was ich bis jetzt gemacht habe.

Zuerst habe ich den Index wie folgt erstellt

create index stamdattst.idx_termknp on stamdattst.termknp(TKNTXT)
where TKNTXT like '%wartung%'

So sieht dann das Select Statement aus

select TKNNR, TKNDATB, TKNTIME, TKNUSER, TKNTXT 
from stamdattst.TERMKNP 
where TKNTXT like '%wartung%'
order by TKNTXT;

Alles zusammen dauert das ca. 10 Sekunden.

Die Suche wird dann über eine Anwendung gesteuert und kann beliebig oft mit unterschiedlichen Such-Text aufgerufen werden.

Das Create des Index bringt allerdings dann einen Fehler, weil IDX File schon vorhanden ist.

Dann war der nächste Ansatz, einfach einen Index über die ganze Datei laufen zu lassen ohne Bedingung. Damit man dies nur einmal machen muss.

Was, aufgrund deiner Erklärung, wenig Sinn macht

Gibt es eine Möglichkeit, das dieses IDX File immer überschrieben wird?

Lg Marco

[andreaspr@aon.at]

Sorry, ich glaub ich hatte dein Problem nicht ganz durchschaut.
Ich schätze du willst immer nach einem anderen Suchbegriff die Sätze ausgewählt bekommen.

Du kannst nur CREATE INDEX und DROP INDEX verwenden.

Allerdings macht ein Index nur dann Sinn, wenn du öfters ein Select mit dem Suchbegriff absetzen möchtest!

Im Normalfall würde auch die DB Temporäre Indice anlegen (MTI). Jedoch ist mir noch nie aufgefallen, dass sie einen Index mit WHERE-Bedingung anlegen würde.

Wenn du das brauchst, müsstest du ihn dir selbst vorgelagert anlegen.
Da gibt es jedoch einiges was zu beachten wäre! (Doppelt erzeugte Indice, Speicherplatz usw.)

Ich würd mir mal den Zugriffsplan für die aktuelle Abfrage anschauen ob man die nicht optimieren könnte. (Ist ALWCPYDTA auf *YES)

lg Andreas

[martrip]

Guten Morgen Andreas.

Stimmt. Genau so brauchen wir das.

Ich kann nicht erklären wieso, doch das create des index über die ganze Datei ohne Where mit dem Textfeld hatte schon einen Performance Gewinn von fast 10 Sekunden gebracht, was uns momentan reicht.

Vielen Dank für die Hilfe

Lg Marco

[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.