nicht angemeldet
Hi!
Ansonsten macht SQL in deinem Fall 3 komplette Datenbank Scans.
Woher weißt du, dass der OP keinen Index verwendet?
Einmal holt es sich die Daten für die Tabelle die du durchsuchen willst. Dann nochmal für den Subquery (wobei das ein wenig schneller gehen sollte, da die Daten bereits im Cache liegen.
Höchstens im Filesystem-Cache, denn ich kann mir nicht vorstellen, dass sie im Query-Cache von MySQL liegen, weil die Subquery jedesmal eine andere ist und nur bei Übereinstimmung auf den Query-Cache zugegriffen werden kann und wird.
Und dann nochmals für die Range im Where. Zudem kann kein Index benutzt werden, da Range keinen Index benutzt.
Du meinst das außere WHERE? In meinem nachgestellten Szenario zeigte EXPLAIN nämlich für die Subquery ein nettes "Using index" an. Natürlich hatte ich einen auf die Kundennummer gelegt.
Und wie entstehen jetzt drei Full Table Scans (angenommen, du meinst das mit "komplette Datenbank Scans")? Ein FROM erzeugt doch noch keinen Scan, oder?. Beim Abarbeiten des äußeren WHERE kommt möglicherweise ein Full Table Scan zum Einsatz. Da hat mir das EXPLAIN keine Indexverwendung angezeigt, was aber auch an meinem zu geringen Testdatenbestand von 5 Datensätzen gelegen haben könnte. Ich denke aber, dass für den beiden Einschränkungen sehr wohl ein Index verwendet werden könnte. Jedenfalls hat die Subquery ja (trotz der 5 Datensätze) einen Index verwendet, da findet also auch kein Full Table Scan statt. Zudem würde er ja bei jeder Subquery-Abarbeitung notwendig sein, weswegen deine 3 nur in einem einzigen Fall stimmen würde.
Die Idee zur Optimierung wäre bei einer MyIsam Tabelle, dass du ALLE Daten in die Programmiersprache holst und dort die kleinstmögliche Kundennummer suchst.
Ich würde ja erst einmal die (nicht) vorhandenen Index untersuchen und die EXPLAIN-Ausgabe analysieren, bevor ich alle Daten antanzen lasse. Außerdem könnte man sowas mit einer Stored Procedure auch gleich im DBMS erledigen lassen.
Lo!