(Ich suche noch einen Link zu einer Seite, auf der unterschiedliche Performance-Tests mit einem MS-
SQL Server gemacht wurden, und dort gab es teilweise unterschiedliche Laufzeitverhalten abhänging von der Satzanzahl. Der scheint sich im Moment aber gut zu verstecken)
Sag Bescheid, wenn Du ihn gefunden hast
Zitat:
Ob das aber wirklich effizienter abgearbeitet wird und wenn, bei welcher Datenmenge und welcher Datenstruktur, hängt sehr stark vom
DBMS und dem Optimizer ab.
Genau! Und an der Stelle erledigt sich eigentlich jede Fragestellung, die nicht exakt an einem System (Hersteller) einer Version (plus Hardware, Cache Größen, Partitionierung etc. pp) entlang läuft .
Ich hab im Rahmen dieses Threads ein paar Sachen auf Oracle ausprobiert. Ein Feld 80 % mit NULL "gefüllt", mit Index, 9 Mio Datensätze. Sucht man nach einem Wert, dessen Häufigkeit deutlich unter 1% ist, wird der Index verwendet, der nächste Wert liegt bei ca 4% Häufigkeit, da wird dann schon Fulltablescan gemacht. Ich bin überrascht.
Das Problem an Threads wie diesen ist, dass immer wieder bestimmte Regeln für richtig erklärt werden, es aber einfach nicht sind, im schlimmsten Fall nicht mal im Besonderen. Thematisch ein Legendenklassiker. Aktuelle Systeme haben sehr pfiffige Optimizer, denen häufig eine Menge Blödsinn und eine Menge KI angedichtet wird.
Deswegen (auch falls ich mich wiederhole)
Prio 1: Fachlich solide Abfrage schreiben und auf den Optimizer vertrauen.
Prio 2: Doku
Prio 3: Tuning, falls nötig, dann aber besonders gut dokumentieren, warum man so komische Abfragen schreibt/ Indizes erstellt/ ..