2.3.조인 종류별 특징 및 활용방안 (2/4) (2.3.2~2.3.3)
2010.12.03 18:36
2.3.2. Sort Merge 조인
- Sort Merge 조인?
연결 할 수 있는 상태로 만드는 재배치를 정렬(Sort) 방식으로 하여, 이들을 서로 연결(Merge)하는 방식
- 장점 : 랜덤 액세스를 하지 않고 정렬된 집합을 스캔해 가면서 머지하기 때문에 연결 속도가 빠름
- 단점 : 정렬작업에 대한 부담 발생
1. TAB1
- FLD1 인덱스 경유 → FLD1 = '111'인 범위 차례로 액세스 → FLD2 Like 'AB%' 체크 → 연결고리 KEY1 값으로 정렬
2. TAB2
- COL1 인덱스 경유 → COL1 = '10'인 범위 차례로 액세스 → 연결고리 KEY2 값으로 정렬
3. 두 개의 정렬 결과를 스캔하여 KEY1 = KEY2 만족 로우를 찾도록 머지하여 운반단위를 채워 추출
머지란?
- 정렬된 양쪽 값을 서로 비교하며 스캔하여 다른 쪽 값이 비교할 값보다 커지면 멈추고,
그 커진 값과 반대편 값을 비교 후 다시 내려가는 방식으로 진행
- 정렬 결과를 스캔하면서 연결되므로 랜덤 액세스 발생 X
※ Nested Loops 조인과 차이
각 컬럼에 인덱스가 있다해도 연결고리인 KEY1, KEY2의 인덱스는 전혀 사용되지 않고 단지 머지의 조건으로만 사용
- 특징
- 동시적 처리 - 조인대상 집합은 각자가 상대 집합의 처리결과와 상관없이 자신의 처리조건만 가지고 액세스 후 정렬
☞ 양쪽 집합이 모두 준비 완료되어야 시작 가능 → 순차적 처리 불가능
- 독립적 처리 - 각 집합의 결과에 영향없이 자신에게 주어진 상수값에 의해서만 범위가 정해짐
- 전체범위 처리 - 정렬 후 조인이 시작되기에 전체범위 처리
- 스캔방식 처리 - 각자 인덱스를 사용하는 경우만 랜덤 액세스가 발생 되고, 연결하는 머지작업은 스캔방식
- 선택적 처리 - 주어진 조건의 모든 컬럼의 인덱스가 존재하여도 모두 사용하지 않음(연결고리 컬럼은 인덱스 사용 X)
- 무 방 향 성 - 조인의 방향과는 거의 무관
- 적용기준
- 전체범위 처리를 할 수 밖에 없는 프로세싱에서 검토
- 상대방 결과 값에 의해 범위를 크게 줄어들지 않을 시 일반적으로 유리함 (but 부분범위 처리 가능여부 고려)
- 처리량이 많으면서 항상 전체범위 처리 할 경우 유리 (주로 스캔방식 처리로 많은 양의 랜덤 액세스를 줄임)
- 연결고리 인덱스 생성이 필요가 없을 시 유용
- 스스로 자신의 처리범위를 줄이느냐에 따라 수행속도 영향이 크기에 효율적 액세스 가능한 인덱스 구성 중요
- 전체범위 처리로 운반단위의 크기가 수행속도에 영향을 크게 미치지 않음 (운반단위 크기에 따라 Fetch 수 차이)
- 처리 데이터량이 적은 온라인 애플리케이션에서 Nested Loops 조인이 유리한 경우가 많기에 Sort Merge 조인 사용 시 고려
- 옵티마이져 Goal이 'ALL_ROWS' 경우, 자주 Sort Merge 조인이나 해쉬조인으로 실행계획이 수립되기에 부분범위 처리를 원할 시 옵티마이져 목표 지정 확인 필요
- 충분한 메모리 활용이 가능하고, 병렬처리로 빠르게 정렬작업 가능 시 대량의 데이터 조인에 매우 유용
※ 요약
- 상대방에게 아무런 값도 받지 않고 자신이 가지고 있는 조건만으로 처리범위가 정해짐
- 랜덤 액세스를 줄일 수 있으나 항상 전체범위 처리
2.3.3. Nested Loops 조인과 Sort Merge 조인의 비교
SELECT a,FLD1, ...., b.COL1, ......
FROM TAB1 a, TAB2 b
WHERE a.KEY1 = b.KEY2
AND a.FLD1 = '111'
AND a.FLD2 like 'AB%'
AND b.COL1 = '10' (삭제)
■ 위의 SQL 처리에 따른 Nested Loops 조인과 Sort Merge 조인 비교
▼ Nested Loops 조인
※ 선접근 테이블의 조건이 삭제되느냐 후접근 테이블의 조건이 삭제되느냐에 따라서 처리 시간 차이 발생
선접근 테이블 조건이 삭제 될 시 중간 결과행 증가로 조인 시 랜덤 액세스 증가
후접근 테이블 조건이 삭제 될 시 조인 후 해당 조건 체크로 큰 차이가 없음.
▼ Sort Merge 조인
※ 체크 조건이 없기 때문에 테이블 전체 정렬로 처리 시간 증가
■ 전체범위 검색 (Order by 사용) 시 Nested Loops 조인과 Sort Merge 조인 비교
▼ Nested Loops 조인
▼ Sort Merge 조인
댓글 0
번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
---|---|---|---|---|
15 | 3.2.1. 스캔(Scan)의 기본유형 [1] | pranludi | 2010.10.19 | 11080 |
14 | 3.2.2. 데이터 연결을 위한 실행계획 | supersally | 2010.10.19 | 10175 |
13 | 3.2.3. 연산 방식에 따른 실행계획 | 노랑배 | 2010.10.18 | 10901 |
12 | 3.1. SQL과 옵티마이져 (1/3) (3.1.1 ~ 3.1.2.2) | 실천하자 | 2010.10.13 | 6813 |
11 | 3.1. SQL과 옵티마이져(1/3) (3.1.1 ~ 3.1.2.2) | supersally | 2010.10.12 | 5879 |
10 | 3.1. SQL과 옵티마이져 (3/3) (3.1.3 ~ 3.1.5) [2] | 실천하자 | 2010.10.08 | 26961 |
9 | 3.1. SQL과 옵티마이져 (2/3) (3.1.2.3 ~ 3.1.2.5) | 노랑배 | 2010.10.06 | 13724 |
8 | 2.1. B-tree 인덱스 | 김진희 | 2010.10.04 | 13021 |
7 | 제2장. 인덱스의 유형과 특징 | 휘휘 | 2010.10.04 | 7272 |
6 | 2.2. 비트맵(Bitmap) 인덱스 | 실천하자 | 2010.10.04 | 20935 |
5 | 2.3. 함수기반 인덱스(FBI, Function-Based Index) | pranludi | 2010.10.01 | 18681 |
4 | 1.1. 테이블과 인덱스의 분리형 | 실천하자 | 2010.09.13 | 13908 |
3 | 1.2. 인덱스 일체형 테이블(Index-Organized Table) | 실천하자 | 2010.09.13 | 9056 |
2 | 1.3. 클러스터링 테이블 | 노랑배 | 2010.09.09 | 9229 |
1 | Front Page | 운영자 | 2010.09.06 | 164254 |