ORDER BY EMAIL인 경우와 ORDER BY DISTANCE인 경우 모두 동일한 실행 계획을 갖게 되는지가 우선 궁금합니다.

특히 LIMIT 없이 ORDER BY EMAIL과 ORDER BY DISTANCE의 수행 시간 차이도 궁금합니다.

혹시 DISTANCE 계산을 하면서 오래 걸리게 되는 것은 아닐까하는 의심이 들어서요.

 저도 거리계산하면서 늦어지는줄 알았는데..아니예요..

계산공식 넣고 order by email 하면 0.05초 나옵니다.

계산공식 빼고 order by email해도 0.05초 정도 나오고요..

확실히 order by distance 가 문제 같습니다.

그래서 좀 고민해봤는데..

limit랑 order by 가 없으면 0.01~0.05정도 나오니..

순간적으로 tmp테이블(distance를 인덱스로 만들고)을 만들어 

insert into tmp

select ..위 쿼리 한다음에

tmp에서 order by distance 한다음에 가져오면 괜찮을까 하고 생각을 해봤는데..

한번요청에 tmp테이블 create하고 index만들고 insert하고 최종적으로 조회하는 단계인데

괜찮을까요?? 아님 더 좋은 방법이 없을까요?? ㅜㅜ

 DISTANCE 를 구하는 것 자체가 각종 수학 함수를 활용하고 있으므로, 해당 부분을 간략화하는 것이 관건인것 같습니다.

무엇보다, 정확한 거리를 구하는 것이 목표가 아니라, 거리순으로 정렬만 하면 되는 것이므로, 대략적인 값으로 정렬하신 후에, 어플리케이션 레벨에서 정밀하게 측정해 재정렬하시거나, 서브쿼리를 사용해서 정확한 DISTANCE를 구한 후, 다시 정렬해주시면 될 것 같습니다.

단순히 위경도 차이의 절대값의 합으로 정렬하셔도 후보군을 구하는 데는 지장이 없을 것으로 보입니다. (추출하는 후보를 조금 더 뽑으면 되니까요 )

( 또한, WHERE 구문 마지막에 두 구문은, 전체 결과를 구한 다음에 서브 쿼리로 따로 빼시는 것이 좋겠습니다. )

 ORDER BY email 이면 email이 키라고 하셨으므로 DB 입장에서는
email 순으로 진행하면서 where 조건에 맞는 애들 200개 뽑아서 계산을 하므로 200번만 계산하면 되는데,
ORDER BY distance라면 where 조건에 맞는 애들 다 뽑아서 아마 jender 등의 조건이 있는 것으로 보아 대략 전체의 30%정도 잡으면 5만번 계산을 하느라 늦는 것으로 생각되는데 질문하신 분은 반드시 "order by "가 문제라고 하시니 손 쓸 방법은 없어보입니다만...

이건 느릴수밖에 없죠.. 위에서 where 조건에 맞는 건수가

10만건이면 10만건을 DISTANCE 에서 계산 하고 그중에

200건을 order by 해오는거랑

email 을 인덱스 이용해서 바로 200건 갖고와서 200건만 DITANCE 를 처리 하는거랑

속도 차이가 날수밖에 없죠..

지금같은 경우는 어플리 케이션 에서 이런 쿼리가 안돌게 수정 하시는방법 밖에 없을거 같네요..

아니면 sort 버퍼 사이즈 증가 tmp 증가 같은 튜닝도 해보시고 성능 테스트 해보세여~