성능고도화 2-2. 소트머지 조인

기본 매커니즘 

 - sort merge 조인은 실제 조인 오퍼레이션 과정은 NL 조인과 다르지 않다. 

   NL 조인과 마찬가지로 outer 조인할 때 순서가 고정된다. 

 - Sort Area는 PGA 영역에 할당되므로 SGA를 경유해 인덱스와 테이블을 엑세스할 때보다

   훨씬 빠르다. ( PGA 사용시 래치 획득 과정이 없다. ) 

 - use_merge 힌트를 사용한다. 

 

소트 머지 조인의 특징 

 - 소트 머지 조인은 조인을 위해 실시간으로 인덱스를 생성하는 것과 다름없다. 

   ( 그래서 조인 컬럼에 인덱스가 없는 상황에서 두 테이블을 독립적으로 읽어 

     조인 대상을 줄일 수 있을 때 유리 ) 

 - 스캔 위주의 엑세스 방식을 사용한다는 점도 소트 머지 조인의 중요한 특징 

 - 하지만, 양쪽 집합에서 정렬 대상 레코드를 찾는 작업만큼은 인덱스를 이용해 random access

   ( 그때 발생하는 random 엑세스랴잉 많다면 소트 머지 조인의 이점이 사라질 수 있음 )

소트 머지 조인이 유용할 때 

 - First 테이블에 소트 연산을 대체할 인덱스가 있을 때 

 - 조인할 First 집합이 이미 정렬돼 있을 때 

 - 조인 조건식이 등치(=) 조건이 아닐 때 

First 테이블에 소트 연산을 대체할 인덱스가 있을 때 

 - 소트 머지 조인은 한쪽 집합은 전체 범위를 처리하고 다른 한쪽은 일부만 읽고 멈추도록 

   할 수 있다. First 테이블 조인 컬럼에 인데스가 있을 때 그렇다. 

    ( sort 연산 생략은 실행계획에 sort join이 하나 밖에 나타나지 않는다. )

 - Second 테이블 조인 컬럼에 대한 인덱스를 이용함에도 Sort Join 오퍼레이션이 나타나지만 

   이때는 소트 연산에 의한 부하가 크지 않다. 

 - 또, 항상 first 테이블을 먼저 읽는 것은 아니다. Second 테이블을 읽어 정렬한 결과를 

   Sort Area에 담는다. 조인 연산을 진행할 때는 first 인덱스 부터 읽기 시작한다. 

소트 머지 조인에서의 부분범위 처리 활용 

 - Second 테이블은 항상 정렬을 수행하므로 전체범위처리가 불가피하지만 First 테이블만큼은 

   중간에 읽다가 멈출 수 있다는 뜻이다. 

   ( 여기서 second 테이블의 전체범위처리가 불가피하다라는 것이 항상 헷갈렸는데 여러번 

     읽고 생각한 것은 second 테이블은 인덱스를 읽어서 부분집합을 만들게 되면 결국은 

     그 부분집합은 다 읽어질 수 밖에 없다. 아마도 그러한 부분을 전체범위처리가 불가피하다 

     라고 표현하지 않았나 싶다. ) 

조인할 First 집합이 이미 정렬 돼 있을 때 

 - 우선, 조인할 First 집합이 조인 컬럼 기준으로 이미 정렬된 상태는 in-line view 에서

    in-line view 안에 group by , order by, distinct  연산을 먼저 수행한 경우, 

    그때는 조인을 위해 다시 정열하지 않아도 되므로 소트 머지 조인이 유리하다. 

 - outer 테이블을 group by 하고서도 sort join 오퍼레이션이 나타날 수 있는데 

   그것은 hash group by로 처리했기 때문이다. 

   이때는 order by를 추가해주면 실제 정렬작업 없이 sort join을 생략할 수 있다. 

 - Second 집합에서는 order by를 추가하더라도 sort join이 발생한다. 

조인 조건식이 등치(=) 조건이 아닐 때 

 - 해시 조인은 조인 조건식이 등치(=) 조건일 때만 사용할 수 있다.