* 질문 등록 시 다음의 내용을 꼭 기입하여 주세요.
|
|
Red Hat Enterprise Linux Server release 7.9 (Maipo) 64bit |
|
|
CUBRID 10.2 (10.2.5.8886-25908b1) |
|
|
SQLGate for CUBRID 9.16.0.0 |
|
|
- |
* CUBRID 응용 오류, SQL 오류 또는 SQL 튜닝 관련된 문의는 반드시 다음의 내용을 추가해 주세요. 비밀글이나 비밀 댓글도 가능합니다.
* 저희가 상황을 이해하고, 재현이 가능해야 알 수 있는 문제들이 많습니다. 가능한 정보/정황들을 부탁합니다.
| 에러 내용 및 재현 방법 | 재현 가능한 Source와 SQL |
| 관련 테이블(인덱스, 키정보 포함) 정보 | CUBRID 홈 디렉토리 아래 log 디렉토리 압축 |
-------------- 아래에 질문 사항을 기입해 주세요. ------------------------------------------------------------------------
'시작하세요! 큐브리드' 책을 보면서 실행계획을 공부해보고 있는 도중 문의사항이 있어 글을 남깁니다.
스칼라 서브쿼리의 동작 방식이 메인 쿼리를 수행하면서 추출된 결과를 서브쿼리의 조건식과 비교해, 조건을 만족하면 결과를 반환하는 방식으로 알고 있습니다.
그러면 athlete 테이블부터 읽고 그 다음 game 테이블을 읽어야 될텐데, 위 실행계획은 반대로 되어 있는것 같아서요.
책에서 실행계획 읽는 법은 가장 안쪽의 가장 윗줄부터 읽는다로 들었는데 (331p 참조),
첨부된 실행계획을 보면 스칼라 서브쿼리부터(game 테이블) 실행한걸로 되어 있습니다.
제가 실행계획을 잘못 이해하고 있는걸까요?
실행계획 읽는 법 가이드 해주시면 감사하겠습니다.
실제 부질의가 결합된 실행순서는 TRACE 정보에서 확인할 수 있습니다. 아래 링크를 참조하세요.
https://www.cubrid.org/manual/ko/11.2/sql/tuning.html#query-profiling
부질의는 외부 참조컬럼 존재 여부에 따라서 correlated와 uncorrelated로 구분이 됩니다. correlated의 경우는 주질의 데이터를 조회한 후 부질의를 조회하고, uncorrelated의 경우는 주질의 실행 전에 부질의 조회가 수행됩니다. TRACE 정보에도 이러한 순서가 명확하게 표현되어 있지는 않네요.
문의 주신 내용처럼 correlated subquery는 참조하는 컬럼의 테이블을 먼저 스캔합니다.