데이터베이스 조인: Difference between revisions
From IT위키
(새 문서: == 조인 기준에 따른 종류 == === 이너 조인 === 일치하는 조인 조건이 있는 데이터만 출력 === 아우터 조인 === 한쪽에만 조인 조건이 있더라...) |
No edit summary |
||
Line 3: | Line 3: | ||
=== 이너 조인 === | === 이너 조인 === | ||
일치하는 조인 조건이 있는 데이터만 출력 | 일치하는 조인 조건이 있는 데이터만 출력 | ||
* 이너 조인은 일치하는 조건이 있어야 출력되기 때문에 아우터 조인처럼 레프트, 라이트 개념이 없다. | |||
* 이너 종류의 종류는 하나인데, 아래의 "자연 조인"은 그냥 사용하는 방식의 차이이고 잘 쓰이지 않으니 참고만 하자. 자연 조인이 아닌 이너 조인이 우리가 일반적으로, 가장 흔히 사용하는 조인 방식이다. | |||
'''(참고) [[데이터베이스 자연 조인|자연 조인]]''' | |||
* 두 테이블에서 공통된 속성(열, attribute)을 기준으로 자동으로 데이터를 결합하는 조인이다. 잘 사용되지 않는다. 하지만 의외로 대부분의 DBMS에서 지원은 된다. | |||
=== 아우터 조인 === | === 아우터 조인 === | ||
한쪽에만 조인 조건이 있더라도 데이터 출력, 데이터가 없는 릴레이션 부분은 null 처리됨 | 한쪽에만 조인 조건이 있더라도 데이터 출력, 데이터가 없는 릴레이션 부분은 null 처리됨 | ||
==== Left Join (Left Outer Join) ==== | |||
* 왼쪽 테이블의 모든 행을 반환하고, 오른쪽 테이블과 일치하는 값이 없으면 '''NULL'''로 채운다. | |||
* 여기서 왼쪽 테이블이라고 하면 먼저 정의한 테이블(아래의 경우 Employees)을 말한다. | |||
<syntaxhighlight lang="sql"> | |||
SELECT * FROM Employees e | |||
LEFT JOIN Departments d ON e.department_id = d.id; | |||
</syntaxhighlight> | |||
==== Right Join (Right Outer Join) ==== | |||
* 오른쪽 테이블의 모든 행을 반환하고, 왼쪽 테이블과 일치하는 값이 없으면 '''NULL'''로 채운다. | |||
* 테이블 순서만 바꿔 적으로 Left와 완전 동일한 결과를 출력한다. 따라서 Left로 통일해서 쓰고 Right는 잘 쓰지 않는 경우가 많다. | |||
<syntaxhighlight lang="sql"> | |||
SELECT * FROM Employees e | |||
RIGHT JOIN Departments d ON e.department_id = d.id; | |||
</syntaxhighlight> | |||
==== [[데이터베이스 Full Outer Join|Full Join (Full Outer Join)]] ==== | |||
* 두 테이블 모두에서 '''일치하는 행은 결합'''하고, '''일치하지 않는 행은 NULL로''' 채워진다. | |||
* 양쪽 테이블의 모든 데이터가 반환되므로 실무적으로 사용할 일은 많지 않다. | |||
<syntaxhighlight lang="sql"> | |||
SELECT * FROM Employees e | |||
FULL JOIN Departments d ON e.department_id = d.id; | |||
</syntaxhighlight> | |||
== 조인 방식에 따른 종류 == | == 조인 방식에 따른 종류 == | ||
Line 28: | Line 62: | ||
* 정렬이 모두 끝난 후 조인 수행 | * 정렬이 모두 끝난 후 조인 수행 | ||
장점 | '''장점''' | ||
* 인덱스 불필요 | * 인덱스 불필요 | ||
* 조인 연산자가 '='이 아닌 경우 nested loop 조인보다 유리한 경우가 많음 | * 조인 연산자가 '='이 아닌 경우 nested loop 조인보다 유리한 경우가 많음 | ||
단점 | '''단점''' | ||
* 정렬 작업으로 인한 메모리 오버헤드가 큼 | * 정렬 작업으로 인한 메모리 오버헤드가 큼 | ||
* 조인 대상 데이터 간 크기의 차이가 큰 경우, 한쪽 정렬이 먼저 완료되어 대기하므로 비효율 발생 | * 조인 대상 데이터 간 크기의 차이가 큰 경우, 한쪽 정렬이 먼저 완료되어 대기하므로 비효율 발생 | ||
최적화 방안 | '''최적화 방안''' | ||
* 데이터를 빨리 읽어들여서 정렬할 수 있도록 메모리(SORT_AREA_SIZE) 최적화 | * 데이터를 빨리 읽어들여서 정렬할 수 있도록 메모리(SORT_AREA_SIZE) 최적화 | ||
Line 49: | Line 83: | ||
* 만들어지는 해시를 기준으로 조인 수행<ref>Sort-Merge와 같이 작업이 먼저 끝나는 테이블이 대기하지 않음</ref> | * 만들어지는 해시를 기준으로 조인 수행<ref>Sort-Merge와 같이 작업이 먼저 끝나는 테이블이 대기하지 않음</ref> | ||
장점 | '''장점''' | ||
* 메모리 성능이 좋은 경우 최적의 성능 발휘 | * 메모리 성능이 좋은 경우 최적의 성능 발휘 | ||
단점 | '''단점''' | ||
* 메모리의 과다한 사용, 메모리 부족시 속도가 현저히 느려짐 | * 메모리의 과다한 사용, 메모리 부족시 속도가 현저히 느려짐 | ||
최적화 방안 | '''최적화 방안''' | ||
* 데이터를 빨리 읽어들여서 해실할 수 있도록 메모리(HASH_AREA_SIZE<ref>HASH_AREA_SIZE는 기본적으로 SORT_AREA_SIZE의 2배로 설정된다.</ref>) 최적화 | * 데이터를 빨리 읽어들여서 해실할 수 있도록 메모리(HASH_AREA_SIZE<ref>HASH_AREA_SIZE는 기본적으로 SORT_AREA_SIZE의 2배로 설정된다.</ref>) 최적화 |
Latest revision as of 13:56, 12 October 2024
조인 기준에 따른 종류[edit | edit source]
이너 조인[edit | edit source]
일치하는 조인 조건이 있는 데이터만 출력
- 이너 조인은 일치하는 조건이 있어야 출력되기 때문에 아우터 조인처럼 레프트, 라이트 개념이 없다.
- 이너 종류의 종류는 하나인데, 아래의 "자연 조인"은 그냥 사용하는 방식의 차이이고 잘 쓰이지 않으니 참고만 하자. 자연 조인이 아닌 이너 조인이 우리가 일반적으로, 가장 흔히 사용하는 조인 방식이다.
(참고) 자연 조인
- 두 테이블에서 공통된 속성(열, attribute)을 기준으로 자동으로 데이터를 결합하는 조인이다. 잘 사용되지 않는다. 하지만 의외로 대부분의 DBMS에서 지원은 된다.
아우터 조인[edit | edit source]
한쪽에만 조인 조건이 있더라도 데이터 출력, 데이터가 없는 릴레이션 부분은 null 처리됨
Left Join (Left Outer Join)[edit | edit source]
- 왼쪽 테이블의 모든 행을 반환하고, 오른쪽 테이블과 일치하는 값이 없으면 NULL로 채운다.
- 여기서 왼쪽 테이블이라고 하면 먼저 정의한 테이블(아래의 경우 Employees)을 말한다.
SELECT * FROM Employees e
LEFT JOIN Departments d ON e.department_id = d.id;
Right Join (Right Outer Join)[edit | edit source]
- 오른쪽 테이블의 모든 행을 반환하고, 왼쪽 테이블과 일치하는 값이 없으면 NULL로 채운다.
- 테이블 순서만 바꿔 적으로 Left와 완전 동일한 결과를 출력한다. 따라서 Left로 통일해서 쓰고 Right는 잘 쓰지 않는 경우가 많다.
SELECT * FROM Employees e
RIGHT JOIN Departments d ON e.department_id = d.id;
Full Join (Full Outer Join)[edit | edit source]
- 두 테이블 모두에서 일치하는 행은 결합하고, 일치하지 않는 행은 NULL로 채워진다.
- 양쪽 테이블의 모든 데이터가 반환되므로 실무적으로 사용할 일은 많지 않다.
SELECT * FROM Employees e
FULL JOIN Departments d ON e.department_id = d.id;
조인 방식에 따른 종류[edit | edit source]
NESTED LOOPS 조인[edit | edit source]
조인 대상 테이블의 인덱스가 있는 경우 사용
- Loop의 기준이 되는 드라이빙/드리븐 테이블 선정
- 드라이빙 테이블 기준으로 반복해서 읽으며 인덱스를 이용한 조인 수행
최적화 방안
- 드라이빙 테이블 선정
- 조인 순서 조정
- 적절한 인덱스 설계
SORT-MERGE 조인[edit | edit source]
조인 대상 테이블에 인덱스가 없는 경우 사용
- 각 테이블의 데이터를 동시에 읽어 들임
- 각 테이블 데이터를 연결 칼럼을 기준으로 정렬
- 정렬이 모두 끝난 후 조인 수행
장점
- 인덱스 불필요
- 조인 연산자가 '='이 아닌 경우 nested loop 조인보다 유리한 경우가 많음
단점
- 정렬 작업으로 인한 메모리 오버헤드가 큼
- 조인 대상 데이터 간 크기의 차이가 큰 경우, 한쪽 정렬이 먼저 완료되어 대기하므로 비효율 발생
최적화 방안
- 데이터를 빨리 읽어들여서 정렬할 수 있도록 메모리(SORT_AREA_SIZE) 최적화
HASH 조인[edit | edit source]
NESTED LOOPS나 SORT-MERGE 사용이 불리한 경우 사용
- 드라이빙 테이블 선정
- 드라이빙 테이블을 우선적으로 해시 생성
- 만들어지는 해시를 기준으로 조인 수행[1]
장점
- 메모리 성능이 좋은 경우 최적의 성능 발휘
단점
- 메모리의 과다한 사용, 메모리 부족시 속도가 현저히 느려짐
최적화 방안
- 데이터를 빨리 읽어들여서 해실할 수 있도록 메모리(HASH_AREA_SIZE[2]) 최적화