View Full Version : SQL: Performance LIKE
andreaspr@aon.at
24-04-13, 12:24
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
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
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
25-04-13, 07:31
Ich glaub dass der Index nur wegen dem ORDER BY benützt wird. Danach selektiert die DB vom Ergebnis die einzelnen Sätze heraus.
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?
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.
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.
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 :)
Allerdings nur, wenn die where-Klausel zum Index identisch ist.
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?