* 질문 등록 시 다음의 내용을 꼭 기입하여 주세요.
|
|
Windows 10 64bit |
|
|
CUBRID 9.3 (9.3.9.0002) |
|
|
SQLGate for CUBRID Developer 9.17.1.0 |
|
|
java, php, odbc 등 입력 |
* CUBRID 응용 오류, SQL 오류 또는 SQL 튜닝 관련된 문의는 반드시 다음의 내용을 추가해 주세요. 비밀글이나 비밀 댓글도 가능합니다.
* 저희가 상황을 이해하고, 재현이 가능해야 알 수 있는 문제들이 많습니다. 가능한 정보/정황들을 부탁합니다.
| 에러 내용 및 재현 방법 | 재현 가능한 Source와 SQL |
| 관련 테이블(인덱스, 키정보 포함) 정보 | CUBRID 홈 디렉토리 아래 log 디렉토리 압축 |
-------------- 아래에 질문 사항을 기입해 주세요. ------------------------------------------------------------------------
귀사가 제공한 정기교육 파일(CUBRID_정기교육.pdf)에서 "질의 튜닝" 부분을 보고 있습니다.
그 중 "스칼라 쿼리 Outer join" 부분이 이해가 되지 않아 문의를 드립니다.
위 튜닝 전 쿼리는 메인 쿼리에서 반환되는 개수만큼(8,633)만큼 스칼라 서브쿼리가 수행되는 쿼리이며 비용은 46 입니다.
이 쿼리를 Outer 조인으로 바꾼 결과가 아래인데, 비용을 보면 305입니다.
튜닝 내용 설명을 보면 메인 쿼리에서 반환되는 결과 건수가 많은 경우는 호출 횟수를 줄이도록,
스칼라 서브쿼리보다 outer join을 사용하여 성능을 개선할 수 있다고 나와 있습니다.
근데 오히려 비용은 outer join으로 수행 시 더 높게 나오는데 이해가 되지 않습니다.
비용이 낮은 플랜을 고르는게 맞지 않나요?
아니면 쿼리 수행 시간으로 판단하는게 맞나요?
스칼라 서브쿼리는 실행 시 0.8 이상 나오고, outer join은 0.5~0.6초 정도 나오네요..
우선, 결론부터 말씀드리면 실행계획에서 비용(cost)만으로 성능 판단이 불가능합니다.
1. 비용 차이가 나는 이유
1-1) 공통 부분
- game g 의 비용(46)은 Scalar Subquery, Outer Join 둘 다 동일 합니다.
1-2) Scalar Subquery
- a.code = g.athlete_code 조건의 비용이 0인 이유는 Main 쿼리 결과 1건을 Scalar Subquery에서 1건만 비교하기 때문에 비용이 낮습니다.
1-3) Outer join
- idx-join (left outer join) 부분에서 비용이 305로 나온 이유는 NL join(Nested Loops Join) 특성상 반복해서 page를 읽기 때문에 값이 클 수밖에 없습니다.
2. trace 확인 결과
* fetch 란 : page를 fix한 회수
- 두 trace 확인 결과 Outer join의 fetch 결과가 더 적기 때문에(page를 읽는 개수가 적기 때문에), 쿼리 수행시간이 더 빠르게 나옵니다.
2-1) Scalar Subquery
Trace Statistics:
SELECT (time: 73, fetch: 43440, ioread: 0)
SCAN (table: game), (heap time: 10, fetch: 8677, ioread: 0, readrows: 8653, rows: 8653)
SUBQUERY (correlated)
SELECT (time: 53, fetch: 34671, ioread: 0)
SCAN (index: athlete.pk_athlete_code), (btree time: 26, fetch: 26018, ioread: 0, readkeys: 8653, filteredkeys: 8653, rows: 8653) (lookup time: 5, rows: 8653)
2-2) Outer join
Trace Statistics:
SELECT (time: 42, fetch: 34788, ioread: 0)
SCAN (table: game), (heap time: 9, fetch: 8677, ioread: 0, readrows: 8653, rows: 8653)
SCAN (index: athlete.pk_athlete_code), (btree time: 24, fetch: 26018, ioread: 0, readkeys: 8653, filteredkeys: 8653, rows: 8653) (lookup time: 4, rows: 8653)