* 질문 등록 시 다음의 내용을 꼭 기입하여 주세요.
centOS6.9_x86 | |
8.4.1.32003 | |
CUBRID Manager 10.1.0.0004 (32bit) | |
java |
* CUBRID 응용 오류, SQL 오류 또는 SQL 튜닝 관련된 문의는 반드시 다음의 내용을 추가해 주세요. 비밀글이나 비밀 댓글도 가능합니다.
* 저희가 상황을 이해하고, 재현이 가능해야 알 수 있는 문제들이 많습니다. 가능한 정보/정황들을 부탁합니다.
에러 내용 및 재현 방법 | 재현 가능한 Source와 SQL |
관련 테이블(인덱스, 키정보 포함) 정보 | CUBRID 홈 디렉토리 아래 log 디렉토리 압축 |
-------------- 아래에 질문 사항을 기입해 주세요. ------------------------------------------------------------------------
궁금한 게 있습니다. 만약
SELECT *
FROM A
INNER JOIN B ON A.key = B.key
LEFT JOIN C ON A.key = C.key
AND C.id = "test"
로 질의 실행계획을 봤을 때 (각 테이블의 key 와 C.id 는 인덱스 등록되어있음) A, B 와 index join 하고 그 결과를 C 와 index join 합니다.
하지만
SELECT *
FROM A
INNER JOIN B ON A.key = B.key
LEFT JOIN C ON B.key = C.key
AND C.id = "test"
로 질의 실행계획을 봤을 때 A, B 와 index join 하고 그 결과를 C 와 sort-merge join 합니다.
코스트는 후자가 더 적습니다.
두 쿼리의 어떤 점 때문에 이런 차이가 발생하나요? 만약 AND조건을 빼면 둘 다 index join을 하고 코스트는 서로 같습니다.
상세한 실행계획 및 인덱스 내용을 확인할 수 없어 올려주신 내용을 기반으로 가정하여(소설..) 제 의견을 드리면 아래와 같습니다.
일단 AND C.id = "test" 조건이 코스트가 적게 나오는 것은 해당 Query상에 유일한 변수 조건이면서 인덱스가 존재하고(단일인지 복합 인덱스인지는 현재 정보로는 알 수는 없지만..) 범위를 줄여주는 조건으로 판단하지만 해당 조건이 없는 경우에는 A와 B에 대해서 조인 키로 = 조건에 해당하는 모든 데이터를 IDX-JOIN으로 수행하기에 C.id가 있는 경우가 시작시점과 함께 범위를 줄여주는 조건으로 Cost가 적게 나오는 것으로 판단하는 것 같습니다. 제 판단이 맞을지는 모르겠지만 각 테이블의 KEY보다는 ID 컬럼이 Unique성을 나타날 것 같습니다.
그리고, C가 LEFT OUTER JOIN이 아니면 C를 Driving Table로 하는 조인순서를 변경하고 IDX-JOIN으로 하면 좋겠지만 순서를 바꿀 수 없기 때문에 A와 B를 IDX JOIN하고 C를 C.id 변수 조건으로 필터링 한 후(조인 데이터 량을 줄임.) Sort Merge Join을 수행하는 것 같습니다.
인덱스 구성 및 데이터 카디널리티등 다양한 환경에 따라 달라지는 부분으로 질문해주신 내용과 부합하지 않을 수 있으며 해당 내용을 참고하여 종합적으로 판단하는 것이 좋을 것 같습니다.
감사합니다.