[MS SQL]8.JOIN심화

JOIN에 대한 추가설명

사실 JOIN은 주어진 쿼리를 효율적으로 처리하기위해 크게 3가지 유형으로 실행되고있다.

1)Nested Loop

 

2)Merege

 

3)Hash

 

Nested Loop

먼저 Nested Loop를 알아보기 위해서 아래의 코드를 실행했을때

SELECT TOP 5*
FROM players AS p
	INNER JOIN salaries AS s
	ON p.playerID = s.playerID

 

이와 같은 실행순서를 거친다. 영어 그대로 중첩Loop를 돌면서 JOIN을 하고있다는건데,

쉽게 생각해서 p와 s의 playerID가 일치하는지 알기 위해 무식한방법으로 2중 for문을 돌려서 playerID를 비교하는 방식이라고 생각하면 된다.-> (진짜 2중포문은 아니고 효율성을 챙기기 위해서 Dictionary를 이용해서 시간복잡도를 최대한으로 줄였을 것임)

 

위의 스크린샷도 FROM으로 p를 줬으니 p를 기준으로 s에 맞추는 것이아닌 내부적으로 s를 기준으로 비교하면서 p를 맞추는것이 효율적으로 판단해서 s로 Index Scan을 진행하며 p와 맞추고있다.

 

정확하게 실행대상을 맞추기위해서 OPTION(FORCE OREER)로 실행시킬수있지만 두 테이블 모두 Scan을 하고있어서 위 코드보단 확연히 느릴것이다.

--NL
SELECT TOP 5*
FROM players AS p
	INNER JOIN salaries AS s
	ON p.playerID = s.playerID
	OPTION(FORCE ORDER)

 

이 방식이 효율적일 때는 부분범위 처리를 할때이다. "상위 5개"같은 데이터를 추출할때 Loop를 돌면서 5개만 추출되면 바로 실행을 종료 시킬수있기 때문에 테이블의 모든 데이터를 조회해야하는 명령어가 아니면 NL 방식이 효율적이어서 이렇게 작동한다는 사실을 알아두자.

 

 

Merge

Merge보다는 Merge Sort라고 기억하는것이 이해해 도움될것이다. 알고리즘의 Merge Sort를 알고있다면 이 부분과 차이점이 없다.

 

양쪽 집합을 Sort 시킨후에 Merge를 시키는것인데,이미 정렬되어있다면 Sort를 건너뛸수도있다.

 

만약 아래의 코드에서 애초에 두 테이블 모두 playerID가 Clustered Index이라면 이미 playerID를 기준으로 정렬되어있는 상태이기때문에 Sort과정이 필요없을 것이.

SELECT *
FROM players AS p
	INNER JOIN salaries AS s
	ON p.playerID = s.playerID

 

Non - Clustered Index를 Sort하고 Merge 경우는 없을까 하는데,  Clustered Index 가 없으면 그렇게 작동하겠지만 위의 데이터의 경우에는 Clustered Index가 존재하는한 어차피 Non-Clustered Index에서 Key값을 알아내고 Clustered Index에서 다시 실제 데이터 값을 찾아야 하기때문에  Clustered를 기준으로 정렬하고 값을 찾는것이더  효율적이다.

 

 

Merge Sort를 이해하고있다면 기준(Outer)과 대상(Inner) 병합시 Outer는 중복되는 값이 없어야지 실행 과정이 간단해진다.또한 정렬되어야하는 값이 너무 많은 경우 비용을 무시할수 없다.

-> 즉 Outer를 어떤걸 선택하느냐에따라 효율이 달라진다.

 

 

Hash

이것도 자료구조를 알고있다면 이해하기 쉬운데, 기존 Merge 방식에서 Sort하거나 NL처럼 값들을 서로 비교하는 비용이 부담스러울때 Hash Table의 장점을 쓸 수있다.

 

과정

1.데이터 수가 적은 쪽으로 Hash Table을 만든다. (많은 쪽을 해봤자 비용만 더 들뿐 같은 결과 값을 뱉음)

 

2.만든 Hash Table을 기준으로 비교하며 값의 유무를 판단

 

특징

1)NL처럼 값을 서로 비교하는것이 아닌Hash Table에 존재하는지의 유무로 판단.

2)Merge처럼 정렬이 필요하지않음

3)인덱스에 영향을 받지않는다. -> 데이터 수가 적은 경우에 이것은 장점으로 작용할 수있음

4)Hash Table을 만드는 비용도 적지는 않기때문에 수행빈도를 고려하며 설계해야함