Join의 필요성 #

관계형 데이터베이스에서 논리적인 관계만으로 테이블간의 관계를 형성하여 원하는 정보를 확인해야 하는 경우가 많이 발생한다. 이러한 경우에 Join을 사용할 경우 매우 유용하다. 하지만 물리적인 연결고리가 없는만큼 Join을 잘못 사용할 경우 원하는 결과는 나올지라도 그에대한 성능이 심각하게 저하되는 현상이 발생할 수 있다.

Join의 성능 #

우선 아래와 같이 3개의 테이블이 있다고 가정하자.

TABLE1 : 총 10,000개의 ROW

TABLE2 : 총 1000개의 ROW

TABLE3 : 총 2개의 ROW

처리방법1
[TABLE1 -> TABLE2 -> TABLE3 으로 Join]
1) TABLE1의 처리범위인 10,000 행의 첫번째 행을 읽는다.
2) 읽혀진 TABLE1의 값에 대응되는 TABLE2의 행을 찾는다 이 엑세스 결과는 TABLE2에 대응되는 행이 존재할수 있고, 없을 수도 있다 그러나 그 성공 여부에 관계없이 작업은 수행된다.
3) 위의 작업에서 성공된 경우는 TABLE2의 Join인 컬럼값과 대응되는 TABLE3의 행을 찾는다. 이 엑세스도 2)와 마찬가지로 성공할수도 있고 없을 수도 있다. 하지만 작업은 성공여부에 관계 없이 수행된다.
4) 다시 TABLE1의 두번째 행을 읽어 위의 작업의 작업을 반복하게 되며 TABLE1의 처리범위가 모두 끝날때 까지 반복된다.

처리결과 : 최소 10,000회 이상 엑세스됨

처리방법2
[TABLE3 -> TABLE2 -> TABLE1 으로 Join]
1) TABLE3의 처리범위인 2개의 행에서 첫번째 행을 읽는다.
2) 읽혀진 TABLE3의 값에 대응되는 TABLE2의 행을 찾는다. 이 엑세스는 TABLE2에 대응되는 형이 하나이상 존재할수도 있고, 없을수도 있다.
3) 위의 작업에서 성공된 경우는 TABLE2의 Join 컬럼값과 대응되는 TABLE1의 행을 찾는다 이 엑세스도 성공할수도 있고 없을수도 있다.
4) 다시 TABLE3의 두번째 로우를 읽어 위의 작업을 반복하고 작업을 종료한다.

처리결과 : 최대 4회 이하의 엑세스

위의 예시에서 Join되는 결과는 동일하다 하지만 결과를 가져오기 위해서 수행되는 작업양은 확연한 차이를 보인다. 1번째 경우는 범위가 큰것에서 작은것 순으로 원하는 값을 찾고, 2번째 경우는 범위가 작은것에서 큰것으로 찾게된다. 따라서 결과가 동일하게 나올지라도 그 결과가 나오기 까지의 성은은 어떻게 Join을 활용하냐에 따라 극명하게 달라질수 있다.

Join의 튜닝 #

Join을 튜닝할대 관계형 데이터베이스에 포함된 옵티마이져에만 의존할 수는 없으므로 쿼리를 작성하는 작성자가 적절한 경로를 지정해줘야 최적의 쿼리를 만들수 있다. 그 방법으로 아래와 같은 방법(예시)을 들 수 있다.

1. Nested Loop Join이 유리한지 Sort Merge Join이 유리한지 판단한다.
2. 연결고리 상태를 확인한다. 연결고리에 이상이 있다면 이미 엑세스 방향이 정해져 있으므로 현 상태의 문제점을 확인하여 인덱스의 추가 여부를 결정하고, 연결고리가 정상인 상태라면 다음 단계를 검토한다.
3. 연결고리를 제외한 컬럼들의 조건에 사용된 연산자와 인덱스의 상태를 비교하여 처리범위를 가장 많이 줄여 주는 조건을 찾는다. 조건에 사용된 컬럼들이 아무리 많고 그들이 사용할 수 있느 인덱스 또한 많더라도 대개의 경우 인덱스 머지를 피하는 것이 유리하기 때문에 가장 최소의 범위로 처리하는 것이 일반적으로 빠르다.
4. 현재의 인덱스가 우리가 찾은 최소의 범위를 액세스 할 수 있도록 구성되어 있는지 확인한다. 확인 결과 그렇지 못하면 그 다음 순서의 최소범위를 찾아 이 경로로 처리되어도 충분할 것인지를 검토한다. 물론 부분범위처리가 가능한 경우라면 처리범위가 넓더라도 수행속도가 충분히 보장되는 경우가 있으므로 이 단계에서는 부분범위처리로 유도할 수 있는지를 잘 살펴보아야 한다. 만약 적절한한 조건을 찾을 수 없었다면 인덱스를 변경시킬 방법을 연구해 보아야한다. 그러나 특정한 엑세스 유형을 위해 함부로 인덱스를 추가하게 되면 기존의 엑세스에 영향을 미칠 수 있으므로 반드시 종합적인 판단을 해야한다.