Ich nehme auch an, dass Sie Oracle verwenden. Und ich empfehle Ihnen auch, dass Sie sich für den Anfang die Plan-Erläuterungs-Webseite ansehen. Es gibt viel zu optimieren, aber man kann es lernen.
Es folgen einige Tipps:
Erstens, wenn jemand Sie mit der Optimierung beauftragt, sucht er fast immer nach akzeptabler Leistung und nicht nach ultimativer Leistung. Wenn Sie die Laufzeit einer Abfrage von 3 Minuten auf 3 Sekunden reduzieren können, schwitzen Sie nicht, sie auf 2 Sekunden zu reduzieren, bis Sie dazu aufgefordert werden.
Führen Sie zweitens eine schnelle Überprüfung durch, um sicherzustellen, dass die Abfragen, die Sie optimieren, logisch korrekt sind. Es klingt absurd, aber ich kann Ihnen nicht sagen, wie oft ich bei einer langsam laufenden Abfrage um Rat gefragt wurde, nur um herauszufinden, dass sie gelegentlich falsche Antworten gab! Und wie sich herausstellte, führte das Debuggen der Abfrage oft auch zu einer Beschleunigung.
Achten Sie insbesondere auf den Begriff „Kartesischer Join“ im Erklärplan. Wenn Sie es dort sehen, stehen die Chancen sehr gut, dass Sie einen unbeabsichtigten kartesischen Join gefunden haben. Das übliche Muster für einen unbeabsichtigten kartesischen Join ist, dass die FROM-Klausel Tabellen durch Komma getrennt auflistet und die Join-Bedingungen in der WHERE-Klausel stehen. Außer, dass eine der Join-Bedingungen fehlt, sodass Oracle keine andere Wahl hat, als einen kartesischen Join durchzuführen. Bei großen Tabellen ist dies eine Leistungskatastrophe.
Es ist möglich, im Erklärplan einen kartesischen Join zu sehen, bei dem die Abfrage logisch korrekt ist, aber ich verbinde dies mit älteren Versionen von Oracle.
Suchen Sie auch nach dem unbenutzten zusammengesetzten Index. Wenn die erste Spalte eines zusammengesetzten Indexes nicht in der Abfrage verwendet wird, verwendet Oracle den Index möglicherweise ineffizient oder gar nicht. Lassen Sie mich ein Beispiel geben:
Die Abfrage lautete:
select * from customers
where
State = @State
and ZipCode = @ZipCode
(Das DBMS war nicht Oracle, also war die Syntax anders, und ich habe die ursprüngliche Syntax vergessen).
Ein kurzer Blick auf die Indizes ergab einen Index für Kunden mit den Spalten (Land, Staat, Postleitzahl) in dieser Reihenfolge. Ich habe die Abfrage in read
geändert select * from customers
where Country = @Country
and State = @State
and ZipCode = @ZipCode
und jetzt lief es in etwa 6 Sekunden statt etwa 6 Minuten, weil der Optimierer den Index gut nutzen konnte. Ich fragte die Anwendungsprogrammierer, warum sie das Land aus den Kriterien weggelassen hatten, und dies war ihre Antwort:Sie wussten, dass alle Adressen das Land gleich „USA“ hatten, also dachten sie, sie könnten die Abfrage beschleunigen, indem sie dieses Kriterium weglassen!
Leider ist das Optimieren des Datenbankabrufs nicht wirklich dasselbe wie das Einsparen von Mikrosekunden an Rechenzeit. Es beinhaltet das Verständnis des Datenbankdesigns, insbesondere der Indizes, und zumindest einen Überblick darüber, wie der Optimierer seine Arbeit erledigt.
Sie erzielen im Allgemeinen bessere Ergebnisse mit dem Optimierer, wenn Sie lernen, mit ihm zusammenzuarbeiten, anstatt zu versuchen, ihn zu überlisten.
Viel Glück beim Optimieren!
