1

다음과 같은 쿼리가 있다고 가정 해보십시오.

SELECT
    t1.c1,
    t2.c2,
    ... more fields from joins ...
FROM t1
LEFT JOIN t2 ON t1.id = t2.id
... more joins ...
GROUP BY t1.field
WHERE ...

그리고 성능 문제가 있고 당신이 커버했다고 생각합니다.모든 일반적인 최적화이러한 유형의 쿼리의 경우,ON,GROUP BY,WHERE등등. 그러나 그것은 아직도 정말로 느리다.


  • 그게 당신의 DB 설계 및 구조 때문에, 우리는 거기에서 무슨 일이 일어나고 있는지 볼 필요가있다, 우리는 적어도 "쇼 테이블"을 알 필요가있다. 및 "설명 쿼리" 명령 - jcho360
  • @ jcho360 나는 내 자신의 질문에 대답했다. 아래를 보라. 다른 누군가가 똑같은 문제를 안고 있었고, 모든 조인이 테이블이 아니라 뷰임을 확인하는 것을 기억하지 못했다. - rgvcorley
  •   당신이 해결했다고 다행이라면, 어쨌든 explain 명령을 살펴보십시오. 그는 여러분이보기에 참여하고 있다고 말할 수 있습니다. 행운을 빈다. - jcho360
  • 예를 들어 내가보기에 합류하고 있다고 말해주지 않았다고 설명했습니다. 색인을 작성하여 색인을 작성 했으므로 모든 조인은 eq_ref 유형이었습니다. 그래서 나는 깨달을 때까지 왜 그렇게 느린지 혼란스러워했습니다! - rgvcorley

1 답변


1

모든 조인이 뷰가 아닌 실제 테이블에 있는지 확인하십시오!

나는 이것이 오히려 명백하다는 것을 알고 있지만, 조인 중 하나가보기에 있다는 것을 잊어 버렸기 때문에 당분간 당황 스러웠다.

이 질문은 내가 직접 답을 찾지 못한 채 물어 보는 질문 이었지만 GROUP BY 쿼리를 최적화하는 다른 게시물에 언급되지 않은 동일한 문제를 가진 다른 사용자를 돕기 위해 게시하고 싶었습니다. JOIN과. 나는 이것이 받아 들여지는지 잘 모르겠지만, 나는 받아 들인 대답을 다음과 같이 덧붙였다.이 포스트관리자가이 게시물을 삭제하려면 불쾌하지 않아야합니다.


  • & quot; 모든 조인이 실제 테이블 및 뷰가 아닌지 확인하십시오. & quot;에 대한 스마트 답변입니다. (와이) - NullPointer

연결된 질문


관련된 질문

최근 질문