나의 향기에 젖다...

1. Nested Loops Join

각 단계를 완료하고 나서 다음단계로 넘어가는게 아니라 한 레코드씩 순차적으로 진행한다.

단, order by는 전체집합을 대상으로 정렬해야 하므로 작업을 모두 완료한 후 다음 오퍼레이션을 진행한다.

다른 조인방식보다 인덱스 구성 전략이 특히 중요하며, 소량의 데이터를 처리하거나 부분범위 처리가 가능한 OLTP성 환경에 적합한 조인방식이다.

2. Sort Merge Join

두 테이블을 각각 정렬한 다음에 두 집합을 머지(Merge)하면서 조인을 수행한다
  - 소트단계:양쪽 집합을 조인 컬럼 기준으로 정렬
  - 머지단계:정렬된 양쪽 집합을 서로 Merge

소트머지 조인은 Outer루프와 Inner루프가 Sort Area에 미리 정렬해둔 자료구조를 이용할분 실제 조인오퍼레이션은 NL조인과 동일 하지만 Sort Area가 PGA영역에 할당되므로 래치획득과정이 없으므로 SGA를 경유하는 것보다 훨씬 빠름

PGA영역에 저당된 데이터를 이용하여 빠름으로 소트부하만 감수하면 NL조인보다 유리

인덱스유무에 영향을 받지 않음.

스캔위주의 액세스방식을 이용 (단, 양쪽 소스 집합에서 정렬 대상 레코드를 찾는 작업은 인덱스를 이용해 Random엑세스 방식으로 처리, 이때 액세스량이 많다면, 소트머지 이점이 사라질수 있음)

대부분 해시조인인 보다 느린 성능을 보이나, 아래와 같은 상황에서는 소트머지 조인이 유용.
  - First테이블에 소트연산을 대체할 인덱스가 있을때
  - 조인할 First 집합이 이미 정렬되어 있을때
  - 조인 조건식이 등치(=)조건이 아닐때

3. Hash Join

해시조인은 소트머지조인과 NL조인의 효과적이지 못한 상황에 대한 대안으로서 개발됨

둘 중 작은 집합을 읽어 Hash Area에 해시 테이블을 생성하고, 반대쪽 큰 집합을 읽어 해시 테이블을 탐색하면서 조인하는 방식

성능을 좌우하는 요소
  - 한쪽테이블이 Hash Area에 담길 정도로 충분히 작아야 함
  - Build Input 해시키 컬럼에 중복값이 거의 없어야 함

언제 사용하면 효과적인가?
  - 조인 컬럼에 적당한 인덱스가 없어 NL조인이 비효율적일때
  - 조인 컬럼에 인덱스가 있더라도 NL조인 드라이빙에서 Inner로 조인액세스량이 많아 Random 액세스 부하가 심할때
  - 소트머지조인하기에는 두테이블의 소트부하가 심할때
  - 수행빈도가 낮고 쿼리수행이 오래걸리는 대용량 테이블을 조인할때

해시테이블은 단 하나의 쿼리를 위해 생성하고 조인이 끝나면 바로 소멸하는 자료구조이므로, 수행빈도가 높은 쿼리애서 사용하면 CPU와 메모리 사욜률을 크게 증가시키고, 래치 경합이 발생하여 시스템 동시성을 떨어뜨림

그러므로 수행빈도가 낮고, 쿼리수행시간이 오래걸리는, 대용량 테이블을 조인할때 주로 사용해야한다.

타 사이트 Join 정리 내용

>> http://blog.naver.com/toyoui46?Redirect=Log&logNo=120144288851

>> http://blog.naver.com/taiha/10076692782

1.해당하는 PK를 삭제한다.
    ALTER TABLE TABLE명 DROP CONSTRAINT PK명;

2.변경하고자 하는 COLUMN으로 Unique Index를 생성한다.
    CREATE UNIQUE INDEX PK명 ON TABLE명(COLUMN명) TABLESPACE TABLESPACE명;

3.PK에 속성을 추가한다.
    ALTER TABLE TABLE명 ADD CONSTRAINT PK명 PRIMARY KEY(COLUMN명);

>>
ALTER TABLE TEMP_TAB DROP CONSTRAINT TEMP_TAB_PK;

CREATE UNIQUE INDEX TEMP_TAB_PK ON TEMP_TAB(COLUMN1, COLUMN2, COLUMN3);

ALTER TABLE TEMP_TAB ADD CONSTRAINT TEMP_TAB_PK PRIMARY KEY(COLUMN1, COLUMN2, COLUMN3);