Umkreissuche sehr langsam

[Sven Rautenberg]

Moin!

Ich starte nochmal ganz oben im Thread, in der Hoffnung auf Beachtung... :)

Meine Umkreissuche ist leider sehr langsam. Bei z.b. 5000 Datensätzen gibt es nur noch ein Timeout.

Das ist angesichts deines Monsterquerys nicht so verwunderlich.

Wenn es um Performance geht, dann ist alles hinderlich, was die Datenbank für die konkrete Abfrage immer wieder neu berechnen muß, obwohl man es problemlos schon selbst vorausberechnen könnte.

Da ist zunächst deine Monster-Entfernungsformel:
1. Die Formel wird sinnloserweise ZWEIMAL gerechnet, einmal für die Spalte selbst, und einmal für die WHERE-Bedingung.
2. Die Angaben der Spalten breite und laenge jeweils von Grad in Radiant umzurechnen ist unnötig, wenn diese Spalten den Wert direkt umgerechnet enthalten würden.
3. Multiplikation mit 6367,41 erscheint ebenfalls überflüssig - das ist nur dazu da, hinterher genaue Kilometerangaben zu erhalten.
4. Sofern du nicht planst, Events im Umkreis mehrerer tausend Kilometer auszugeben, dürfte der gute alte Pythagoras a²+b²=c² die Berechnung vermutlich deutlich beschleunigen. Da hast du in Deutschland zwar das "Problem", dass die Breiten nicht so lang sind, wie die Längen, aber das kriegt man mit einem Mittelwertfaktor recht gut kompensiert. Alternativ könntest du natürlich auch das Gauss-Krüger-Koordinatensystem verwenden, damit hättest du die Probleme dann gar nicht.

Dann dein JOIN zwischen PLZ des Events und PLZ der Ortstabelle: Den halte ich für überflüssig, weil auch datentechnisch zweifelhaft. Produziere Redundanz, speichere die für die Umkreissuche zu nutzenden Koordinaten direkt im Event-Datensatz. Das spart dir den JOIN. Denn es ist nicht anzunehmen, dass sich a) die Positionen von Postleitzahlen verändern, und b) wenn sich bei den PLZ was tut, dann aufgrund von Umstrukturierungen bei der Post, nicht weil wir Kontinentaldrift haben. Das Event, einmal geplant, hat seinen festen Ort, egal was die Post macht.

Wenn du Redundanz produzierst, indem du die Koordinaten bei der Speicherung des Events ermittelts und dazuspeicherst, hast du auch deutlich weniger Einschränkungen bei deiner PLZ-Tabelle. Die darf dann so ausführlich werden, wie du magst, und muß nicht auf Performance getrimmt werden - denn sie wird nur für das Auffinden der Koordinaten eines Events benutzt, das darf gerne eine Sekunde dauern.

Im Resultat hast du dann nur noch eine Suche in einer Tabelle. Die wäre aufgrund der WHERE-Bedingung für den Umkreis, die sich nicht indizierbar machen läßt, leider ein Full-Table-Scan - mit dem Anfügen von einschränkenden Vorbedingungen (Event muß in der Zukunft liegen, darf nicht gesperrt sein) könnte das aber im Ergebnis schon schnell genug sein.

Alternativ: Die Umkreis-Einschränkung aus dem WHERE rauslassen, stattdessen den Entfernungswert des Pythagoras in die abgefragten Daten übernehmen, danach sortieren lassen und mit LIMIT nur die dichtesten Events verwenden. Damit ergibt sich automatisch eine Einschränkung des Umkreises - jetzt nicht mehr nach Entfernung, sondern es werden einfach die X dichtesten Events ausgegeben.

Alternativ könnte man als Nachbrenner-Filter auch mit HAVING arbeiten, um die Events nach Entfernung auszusortieren.

- Sven Rautenberg