Tabellen für viele kleine Datensätze optimieren

[jobo]

Natürlich ist das keine schlechte Idee! Ich muss meine Aussage "Optimizer kann man eh nicht nachvollziehen" etwas gerade rücken.
Im Zuge von Hibernate, JPA und Persistenzframeworks ist es trendy, die DB als Blackbox zu betrachten. Das Verständnis der Abläufe innerhalb der Blackbox ist damit per Definition ausgeblendet. Sehr bequem, Schuld ist im Zweifel der DB Admin.
Das mag in vielen Fällen (z.B. kleine Projekte, wenig User / Daten) gut gehen, kann aber auch voll in die Hose gehen.

Daher sollte man sich schon um ein gewisses Verständnis von (grundlegenden) DB Verfahren bemühen.
Ein Tuning der DB funktioniert im Produktivbetrieb übrigens am besten bei der Verwendung von Views, hier kann man nachträglich Verbesserungen anbringen bzw. sogar testen, ohne der Anwendung ein Haar zu krümmen, z.B. über Optimizer Hints..

[Dejan Vu]

Zitat:

Zitat von BUG (Beitrag 1265312)

Die Annahme, dass die Optimierer nach festen Regeln optimieren, ist meines Wissens falsch.

Da jedes Programm nach 'festen Regeln' (nämlich dem Code) arbeitet, ist das 100% korrekt (die festen Regeln). Nur frage ich mich, wer das behauptet. Ich habe nur grob skizziert, wie ein Optimierer bzw. der Strategieauswähler arbeitet. Da muss ich auch nicht lange überlegen, in welcher Reihenfolge ich die Dinge abarbeiten und großartige Kombinationen, die alle durchzutesten sind, sehe ich auch nicht. Deshalb liegen die ja auch manchmal daneben, eben weil sie ziemlich starr sind. Es ist wirklich kein Hexenwerk, was da abgeht: Das Statement (meistens ja ein SELECT) wird in einen Baum überführt (das macht der Parser), dann wird 'gekürzt', d.h. gleiche Fragmente zusammengefasst und dann rechnet man für die einzelnen Knoten die beste Strategie nach Brute Force aus. Hierbei wird eine Performancefunktion angewandt, die mit den Statistiken gefüttert wird. Da mittlerweile der I/O-Durchsatz eine entscheidende Rolle spielen kann (SSD, HD, RAM) wird sich das, wenn man die Statistiken erweitert, auch entsprechend auswirken. Wichtig ist: Man muss diese Statistiken pflegen, also im Rahmen eines Wartungsplans immer mal wieder neu erstellen lassen.

Aber da ich nicht alle Optimierer kenne, sondern eigentlich nur 2 (SQL-Server und einen für ein RDBMS selbst entwickelten) kenne ich die Magie hinter anderen Optimizern natürlich nicht. Nur eines kann ich mir nicht vorstellen: Das man irgendwelche Kombinationen durchprobiert, denn da gibt es eigentlich keine. Aber wenn ihr mit 'nicht regelbasiert' Fuzzy-Logik meint, dann ist das natürlich korrekt, denn es ist eine analoge Funktion, die 'ausrechnet', wie teuer ein bestimmtes Verfahren ist und anhand dessen wird bestimmt, was jetzt das beste ist. Also nicht: 'Index-Seek < Index-Scan < Table-Scan'.

Zitat:

Zitat von jobo (Beitrag 1265330)

Daher sollte man sich schon um ein gewisses Verständnis von (grundlegenden) DB Verfahren bemühen.

Genau. Und wie Du schon sagtest: Probieren, Probieren, Probieren. Denn nur aus der Stoppuhr (bzw. die IO-Statistik) spricht die Wahrheit. Amen.

[DSP]

@to: Mal ne dumme Frage, wie ist denn jetzt das Tabellendesign und der Stresstest ausgegangen?