Moin
ich habe folgendes Problem:
SELECT SQL_CALC_FOUND_ROWS users.*, dest.latitude, dest.longitude, ACOS(
SIN(RADIANS(src.latitude)) * SIN(RADIANS(dest.latitude))
+ COS(RADIANS(src.latitude)) * COS(RADIANS(dest.latitude))
* COS(RADIANS(src.longitude) - RADIANS(dest.longitude))
) * 6380 AS distance, FROM users LEFT JOIN postalcodes_de src ON (src.postalcode='01855' AND src.placename='Sebnitz') LEFT JOIN postalcodes_de dest ON (dest.postalcode=users.zip AND dest.placename=users.city) WHERE CONCAT(users.zip,users.city) IN (
SELECT CONCAT(dest.postalcode,dest.placename) FROM postalcodes_de dest
LEFT JOIN postalcodes_de src ON (src.postalcode='01855' AND src.placename='Sebnitz')
WHERE (ACOS(
SIN(RADIANS(src.latitude)) * SIN(RADIANS(dest.latitude))
+ COS(RADIANS(src.latitude)) * COS(RADIANS(dest.latitude))
* COS(RADIANS(src.longitude) - RADIANS(dest.longitude))
) * 6380 ) <=20) ORDER BY distance ASC LIMIT 0,4
Dies ist der Ansatz einer Umkreissuche. Leider dauert die IN-Clause unverhältnismäßig lange.
Das Problem wird sicherlich hier liegen: DEPENDENT SUBQUERY dest index NULL country 1724 NULL 16864 Using where; Using index; Using join buffer
Dies ist die Ausgabe "EXPLAIN" für das Subquery im "IN". Die Indexe sind aber richtig gesetzt. Dies habe ich schon nachgeprüft.
Wie könnte ich das performanter gestalten?
Gruß Bobby
--
-> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <-
### Henry L. Mencken ###
-> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <-
### Viktor Frankl ###
ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:)
-> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <-
### Henry L. Mencken ###
-> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <-
### Viktor Frankl ###
ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:)