Performanceproblem Umkreissuche

[dedlfix]

Tach!

SELECT @a, @a:=@a+1

> Obiges ist auch dusselig.  
> Man muss der Benutzervariablen schon einen Wert zuweisen bei der Deklaration.  
  
Muss man nicht, jedenfalls gibts ohne Erstzuweisung keinen Fehler. @a ist dann nur NULL. Außerdem ist das nur eine Zuweisung. Es ist nicht gesagt, dass nicht noch anderswo eine Erst-Zuweisung erfolgt. Eine Deklaration ist nicht erforderlich.  
  

> ~~~sql
  

> SELECT @a:=1, @a:=@a+1  
> 

Das ist nicht dasselbe wie obiges Statement. Ziel ist anscheinend, dass im ersten Ergebnisgfeld der bisherige Wert ausgegeben wird und nicht irgendwas jetzt erst zugewiesenes. Im zweiten soll anschließend die Inkrementierung stattfinden.

Ich würde es an Bobbys Stelle also auf jeden Fall ausprobieren.

Ich würde mich an Bobbys Stelle auch nicht nach Ausprobieren darauf verlassen, dass es so bleibt.

Anderes Beispiel: Nichtmal auf die EXPLAIN-Ausführungsplan-Informationen kann man sich verlassen, wenn sich der Datenbestand ändert. Bei drei Datensätzen ist ein Fulltable-Scan kein Problem, bei sehr vielen lohnt sich die Verwendung eines Index eher. Somit kann es beim selben Statement zu unterschiedliche Ausführungen kommen.

Ich habe dmit bisher überhaupt nie Probleme gehabt und benutze es in diversen Statemants zur Feststellung von Aufsetzpunkten in sortierten Ausgaben. (Listen von Duplicates)

Und du bist dir auch sicher, dass in deinen Fällen ebenfalls die Zuweisung und die Verwendung auf SELECT und WHERE verteilt ist? In dem Fall müsste noch dazu irgendwer garantieren, dass die Select-Ausdrücke gleichzeitig zum Filter-Vorgang des WHERE berechnet werden, und nicht zuerst die Datenmenge in einem Rutsch eingeschränkt wird und anschließend erst die SELECT-Ausdrücke berechnet werden.

dedlfix.