본문 바로가기

SQL/친절한 sql 튜닝

[5주차] 소트 머지 조인

4.2 소트 머지 조인

1. SGA vs PGA
2. 기본 메커니즘
3. 소트 머지 조인이 빠른 이유
4. 소트 머지 조인의 주 용도
5. 소트 머지 조인 제어하기
6. 소트 머지 조인 특징 요약

 

4.2 소트 머지 조인

대량 데이터 조인에서 인덱스가 효과적이지 않을때

NL 조인 대신에 소트 머지 조인을 사용한다. 

1. SGA vs PGA

  SGA
System Global Area
PGA
Private Global Area
  공유 메모리 영역 독립적인 메모리 공간

프로세스에 종속적인 고유 데이터를 저장하는 용도
    PGA 공간이 부족하면
TEMP테이블 스페이스 사용
캐시된 데이터 공유 가능? 여러 프로세서가 캐시된 데이터를 공유 한다  
동시 엑세스 가능? 프로세서가 동시에 엑세스 못한다.  
Lock 매커니즘 존재함? 경쟁 있음.
동시에 엑세스하려는
프로세서 간
액세스를 직렬화 한다
Lock 매커니즘 == 래치가 존재함
래치 매커니즘 불필요
경쟁 없음
이유: 다른 프로세서랑 공유하지 않는 독립된 메모리 공간 사용해서.
    같은 데이터를 읽을때
SGA 버퍼 캐시에서 읽을 때보다
PGA 독립 메모리에서 읽는게 빠르다
블록을 읽을때 버퍼 Lock 발생함? DB 버퍼 캐시
: 데이터 블록, 인덱스 블록을 캐싱함
블록을 읽을때 버퍼 Lock 발생함.
 

 

 

 

2. 기본 메커니즘

두 단계로 진행한다.

소트 단계 머지 단계
양쪽 집합을
조인 컬럼 기준으로
정렬한다
정렬한 양쪽 집합을
서로
머지한다.
두 번함
테이블이 두개라서
정렬된 두개의 테이블을 합친다.

1) 공통 컬럼이 정렬이 되어있어서 풀스캔 안한다.

2) 정렬되어 있어서 필요한 부분을 빨리 찾아서 사용한다.

3) 정렬 == 인덱스 라서

인덱스가 없지만 인덱스처럼 빨리 사용함.

4) 인덱스를 사용하는 NL조인은 (1)랜덤 액세스로 인해 블록을 통쨰로 읽어와서 비효율 존재 (2) 건건이 DB버퍼 캐시 경유, 래치 획득, 캐시버퍼 체인 탐색, 못찾으면 디스크 찾기 를 해야하는데. 소트머지조인은 안해도됨. 그래서 빠름

3. 소트 머지 조인이 빠른 이유

NL조인이 느리다 소트 머지 조인이 빠르다
전통적인 조인 방식  
대량 데이터 조인시 성능이 매우 느리다 sort Area에 미리 정렬해둔 자료구조 이용함
조인 프로세싱은 NL조인과 같음
인덱스를 사용함 인덱스 사용 안함
모든 블록을 랜덤 액세스 방식으로
건건이
DB 버퍼캐시를 경유해서 읽는다
양쪽 테이블로 부터 
조인 대상 집합을
일괄적으로 읽어
PGA에 저장한다
인덱스, 테이블
모든 블록에
래치 획득
캐시버퍼 체인 스캔 과정
못찾으면
건건이 디스크에서 읽어온다.
래치 획득 과정이 없다.

  조인 전에 
양쪽 집합에
소트 연산을 한다
  양쪽 테이블의
대상 집합을 읽을 때
DB 버퍼캐시 경유한다.
인덱스 사용한다

이건 어쩔 수 없다.
버퍼캐시 탐색 비용
랜덤 액세스 부하

 

 

 

4. 소트 머지 조인의 주 용도

해시조인이 짱이긴한데

1. 조인 조건식이 등치 조건이 아닌 대량 데이터 조인

2. 조인 조건식이 아예 없는 조인(Cross Join, 카데시안 곱)

이럴 때는 소트 머지 조인 사용한다.

 

 

 

 

5. 소트 머지 조인 제어하기

 

힌트정리

NL조인 use_nl(c)
소트 머지 조인 use_merge(c)
해시 조인 use_hash(c)

 

1) 소트 : sorted 대상을 찾기 위해 테비을 액세스시 인덱스 사용한다.

2) 머지

6. 소트 머지 조인 특징 요약

1. 인덱스 아니지만 정렬 사용함. 그래서 빨라

2. PGA 사용해서 공용 메모리가 아닌 독점 메모리라 래치 획득 과정 안들어감. 그래서 빨라

래치? 프로세스간에 동시에 요청오면 캐시된 데이터를 동시에 액세스 불가능.. 줄세우고 Lock함

3. 버퍼캐시 경우 안함. 그래서 빨라

4. 인덱스 유뮤에 따라 영향 안받아. 어짜피 정렬하니깐 ㅎㅎ -> 조인 컬럼에 인덱스가 없어도 괜츈

5. 조인 대상 집합을 줄임

6. 스캔 위주 액세스 방식. 그래서 빨라

 

@@ 스캔 위주의 조인 방식

Inner 테이블을 반복 액세스하지 않으므로

머지 과정에서 Random 액세스가 발생하지 않는 것이다.

하지만, Random 액세스가 전혀 없는 것은 아니다.

각 테이블 검색 조건에 해당하는 대상 집합을 찾을 때 인덱스를 이용한 Random 액세스 방식으로 처리될 수 있고,

이때 발생하는 Random 액세스량이 많다면 Sort Merge Join의 이점이 사라질 수 있다.

 

https://velog.io/@jooh95/DB-Scan-%EC%A2%85%EB%A5%98-%EC%A0%95%EB%A6%AC

'SQL > 친절한 sql 튜닝' 카테고리의 다른 글

[7주차] 6.2 Direction Path I/O 활용  (0) 2022.05.01
[6주차] 소트 튜닝  (0) 2022.04.24
[4주차] 인덱스 튜닝  (0) 2022.04.10
[3주차] 테이블 액세스 최소화  (0) 2022.04.03
인덱스  (0) 2022.03.28