Matti Mäkitalo: mysql: NAHE Ergebnisse

Beitrag lesen

Hi,

MySQL hat ja gewisse Probleme mit Indizes auf berechneten Werten.

Ein nicht vorhandenes Feature mag für den Anwender ein Problem sein, aber nicht für das System selbst. Abgesehen davon, welchen berechneten Wert sollte denn der Index speichern, wenn einer der Operanden erst zur Abfragezeit bekannt ist? Du kannst deswegen ja noch nicht einmal eine Spalte mit einem selbst berechneten Wert einfügen. Nur wenn letzteres ginge, wäre auch ein berechneter Index möglich.

Ich könnte mich rausreden und sagen, dass der OP nicht gesagt hat, dass die Werte nicht dauerhaft konstant wären. Immerhin (auf Beispiel 1 bezogen) wird sein Geburtstag  wohl eher nicht wild im Jahr hin- und herspringen *fg*. Aber du hast natürlich recht.

Man könnte daher mal ausprobieren, die Abfrage aufzuteilen in die Elemente, die größer sind, und diejenigen, die kleiner sind, und beide Abfragen auf n Elemente beschränken (n - gewünschte Zeilenzahl). Die 2n Elemente dann mit der Betrags-Logik behandeln. Nur mal so als Tipp ins Blaue hinein, könnte bei großer Zeilenzahl und kleinem n schneller sein als den Betrag zum Zielwert für alle zu berechnen.

Die Frage ist, ab oder bis zu wieviel Datensätzen ist der eine Ansatz schneller als der andere? Der eine hat den Aufwand alle Datensätze berechnen zu müssen, der andere muss zwei Abfragen laufen lassen und diese sortieren, limitieren und diese dann berechnen.

Eins der Dinge, die ich beim DB-Optimieren gelernt habe: ausprobieren und messen. Deswegen schrieb ich ja auch ausprobieren dazu.

Bis die Tage,
Matti