Nehmen wir folgendes Beispiel...
Die Überlegungen, die hier angestellt werden, würde ich heutzutage eher im Bereich Legendenbildung ansiedeln.
Konkret stammt das beschriebene Verhalten vielleicht von einer Oracle
DB 7, 8, max 9 mit RBO oder einem neueren System, das per Schalter abwärtskompatibel eingestellt ist.
Stimmt, ist fast ein Jahrzehnt her und war Oracle 8.
Grundsätzlich gehe ich immer her und schaue zuerst, wie bekomme ich mit einem lesbaren Statement mein Ergebnis, auf Performance... wird erstmal nicht geachtet, sondern auf eine möglichst einfache und korrekte Abbildung der fachlichen Anforderung. Das hat Priorität. Rumexperimentiert wird erst dann, wenn aktuelle Statistiken... nicht mehr helfen und man einen anderen Weg suchen muss, weil der einfachste Weg nicht auf vertretbare Weise zum Ziel führt. Klimmzüge erst dann, wenn es anders nicht geht.
Generell sollte heute jedes System, das Statistiken beherrscht, eine solche Aufgabe sinnvoll lösen. Und zwar nicht mittels Mutmaßung, es könnte sich um 10% Einschränkung handeln. Auch wenn eine Bedingung "id=4" sehr selektiv aussieht- man könnte ja sogar fast denken, es sei ein Primärschlüssel mit Top Einschränkung =100%- es kann genausogut eine vollkommen wirkungslose Einschränkung sein, weil einer der anderen Joins ggF. gegen einen einzigen Datensatz läuft und id=4 für den gesamten Rest gilt.
id=4 hat ja erstmal überhaupt keine Aussage, id könnte ja auch immer 4 sein, also ein über die gesamte Tabelle geltender, konstanter Wert. Dann hilft das hier natürlich nichts. Die Einschränkung mit id=4 war hier nur beispielhaft gemeint, in der konkreten Situtation wurde die Tabelle mit dem kleinsten Volumen auf ca. 3% der enthaltenen Datenmenge eingeschränkt, mit dem Resultat, dass in dem konkreten Fall auch die übrigen Tabellen auf eine ähnliche Teilmenge eingeschränkt werden konnten. Der Optimiser hat das da halt beim ursprünglichen Statement irgendwie nicht hinbekommen. (Egal, ist Schnee von vorgestern.)
Die Systemstatistiken sollten da helfen.
Also auch wenn es das alles mal gab und in entsprechend alten Systemen immernoch gibt. Aktuell sollte man bei der Formulierung von
SQL Statements durchaus unbefangen vorgehen, zumindest bevor man Annahmen trifft, die nicht (mehr) stimmen.
Ausnahme wäre, man arbeitet gezielt an einem alten Oracle 7 oder 8. Dann besser die 20(oder 15?) Regeln des RBO durchlesen und befolgen. Bei anderen Systemen entsprechend.
Am Ende bleiben dann vielleicht ein paar Prozent problematischer Abfragenfälle, die etwas Forschung benötigen, einen gezielten Optimzer Hint oder vielleicht sogar eine Denormalisierung des DM.
Prinzipiell beschreibst Du das Vorgehen, wie ich es auch immer gehandhabt habe.
Probleme werden erst (und nur dann) gelöst, wenn sie auftreten. Ein voraussschauende Optimierung, mit Behebung von Problemen, deren Existenz nicht bewiesen ist, erfolgt selbstverständlich nicht.