결합

기능적 관점으로 구분하는 결합의 종류

크로스 결합 - 모든 결합의 모체

데카르트 곱이라고 불리는 연산으로, 2개 테이블의 레코드에서 가능한 모든 조합을 구하는 연산
크로스 결합이 실무에서 사용되지 않는 이유
- 이러한 결과가 필요한 경우가 없음
- 비용이 매우 많이 드는 연산
실수로 사용한 크로스 결합
```
SELECT *
FROM Employees, Departments;
```
- 결합 조건이 없으므로 DBMS는 두 개의 테이블에서 나올 수 있는 모든 조합을 생성
- 이러한 실수를 막으려면 표준 SQL에 맞게 결합 구문을 사용하는 것이 좋음

내부 결합 - 왜 ‘내부’라는 말을 사용할까?

내부는 ‘데카르트 곱의 부분 집합’이라는 의미

기능적으로 상관 서브쿼리를 사용해 대체 가능한 경우가 많음

SELECT E.emp_id, E.emp_name, E.dept_id,
     (SELECT D.dept_name
        FROM Departments D
       WHERE E.dept_id = D.dept_id) AS dept_name
FROM Employees E;

내부 결합과 상관 서브쿼리 중 내부 결합을 사용하는 것이 좋음
- 상관 서브쿼리를 이용하면 결과 레코드 수만큼 상관 서브쿼리를 실행하므로 내부 결합보다 비용이 높음

외부 결합 - 왜 ‘외부’라는 말을 사용할까?

내부 결합과 외부 결합은 배타적인 연산
외부 결합은 ‘데카르트 곱의 부분 집합’이 아니라는 읨
외부 결합의 종류
- 왼쪽 외부 결합
- 오른쪽 외부 결합
- 완전 외부 결합
마스터 테이블 쪽에만 존재하는 키가 있을 때 해당 키를 제거하지 않고 결과에 남김

내부 결합과 외부 결합의 차이

외부 결합은 마스터 테이블의 정보를 모두 보존하기 위해 NULL을 생성
크로스 결합과 내부 결합은 NULL을 생성하지 않음

자기 결합 - ‘자기’란 누구일까?

자기 자신과 결합하는 연산으로 같은 테이블 (또는 같은 뷰)을 사용해 결합
같은 테이블에 별칭을 붙여 마치 다른 테이블인 것처럼 취급

결합 알고리즘과 성능

옵티마이저가 어떤 결합 알고리즘을 선택할지 여부는 데이터 크기 또는 결합 키의 분산에 의존

Nested Loops

결합 대상 테이블(Table_A, driving table or outer table)에서 레코드를 하나씩 반복해가며 스캔
Driving table의 레코드 하나마다 내부 테이블(Table_B, Inner table)의 레코드를 하나씩 스캔해서 결합 조건에 맞으면 리턴
이러한 작동을 Driving Table의 모든 레코드에 반복

특징
- 접근하는 레코드 수는 결합 대상인 두 테이블 레코드 수의 곱
- 한 번의 단계에서 처리하는 레코드 수가 적으므로 Hash 또는 Sort Merge에 비해 메모리 소비가 적음
- 모든 DBMS에서 지원
- 구동 테이블이 작을수록 Nested Loops의 성능이 좋음
구동 테이블의 중요성
- 내부 테이블의 결합 키 필드에 인덱스가 존재할 경우 내부 테이블의 반복을 줄일 수 있음
- 구동 테이블이 작고 내부 테이블의 결합 키에 인덱스가 존재하는 것이 SQL 튜닝의 기본
Nested Loops의 단점
- 결합 키가 내부 테이블에 대해 유일하지 않은 경우 반복이 발생하므로 성능이 낮아짐
  - 이러한 경우 구동 테이블로 큰 테이블을 선택할 수 있음
  - 내부 테이블에 대한 구동 테이블의 접근이 기본 키로 수행되므로 항상 하나의 레코드로 접근하는 것이 보장됨

Hash

Hash Join

결합 과정
1. 작은 테이블을 스캔하고 결합 키에 해시함수를 적용해서 해시값으로 반환
2. 큰 테이블을 스캔하고 결합 키가 해시값에 존재하는지 확인
특징
- 결합 테이블로부터 해시 테이블을 만들어서 활용하므로, Nested Loops에 비해 메모리를 크게 소모
- 메모리가 부족하면 저장소를 사용하므로 지연 발생
- 출력되는 해시값은 입력값의 순서를 알지 못하므로 등치 결합에만 사용할 수 있음
Hash가 유용한 경우
- Nested Loops에서 적절한 구동 테이블(상대적으로 충분히 작은 테이블)이 존재하지 않는 경우
- 구동 테이블로 사용할만한 작은 테이블은 있지만, 내부 테이블에서 히트되는 레코드 수가 너무 많은 경우
- Nested Loops의 내부 테이블에 인덱스가 존재하지 않는 (또는 여러 가지 사정에 의해 인덱스를 추가할 수 없는) 경우
주의할 사항
- 초기에 해시 테이블을 만들어야 하므로 Nested Loops에 비해 소비하는 메모리 양이 많음
  - OLTP(Online Transaction Processing) 처리를 할 때 사용하면 안됨
  - 야간 배치 또는 BI(Business Intelligence)/DWH(Data Warehouse)와 같은 시스템에 한해 사용
- 양쪽 테이블의 레코드를 전부 읽어야 하므로 풀 스캔에 걸리는 시간 고려

Sort Merge

결합 대상 테이블들을 각각 결합 키로 정렬하고 일치하는 결합 키를 찾으면 결합
특징
- 대상 테이블을 모두 정렬하므로 Nested Loops보다 많은 메모리를 소비
- 동치 결합 뿐만 아니라 부등호를 사용한 결합에도 사용할 수 있음
- 테이블이 결합 키로 정렬되어 있다면 정렬을 생략할 수 있지만 이는 구현 의존적
- 한 쪽 테이블을 모두 스캔한 시점에 결합을 완료함
Sort Merge가 유용한 경우
- 테이블 정렬을 생략할 수 있는 경우에만 고려

의도하지 않은 크로스 결합

삼각 결합에서 결합 조건이 존재하지 않는 두 테이블을 먼저 결합할 경우 크로스 결합이 발생
비교적 큰 테이블끼리 크로스 결합을 할 경우 성능 문제 발생
크로스 결합이 발생하는 두 테이블의 결합 조건을 설정할 수 있고, 그 결합 조건이 결과에 아무런 영향도 주지 않을 경우 크로스 결합 회피 가능

결합이 느리다면

상황에 따른 최적의 결합 알고리즘

이름	장점	단점
Nested Loops	‘작은 구동 테이블’ + ‘내부 테이블의 인덱스’라는 조건이 있다면 굉장히 빠름 메모리 또는 디스크 소비가 적으므로 OLTP에 적합 비동기 결합에서도 사용 가능	대규모 테이블들의 결합에는 부적합 내부 테이블의 인덱스가 사용되지 않거나, 내부 테이블의 선택률이 높으면 느리다
Hash	대규모 테이블들을 결합할 때 적합	메모리 소비량이 큰 OLTP에는 부적합 메모리 부족이 일어나면 TEMP 탈락 발생 등가 결합에서만 사용 가능
Sort Merge	대규모 테이블들을 결합할 때 적합 비등가 결합에서도 사용 가능	메모리 소비량이 큰 OLTP에는 부적합 메모리 부족이 일어나면 TEMP 탈락 발생 데이터가 정렬되어 있지 않다면 비효율적

결합 대상 레코드 수에 따른 최적의 결합 알고리즘
- 소규모 - 소규모: 어떤 알고리즘을 사용해도 성능 차이가 크지 않음
- 소규모 - 대규모: 대규모 테이블의 결합 키에 인덱스를 만들어 Nested Loops를 사용. 하지만 내부 테이블의 결합 대상 레코드가 너무 많다면 구동 테이블과 내부 테이블을 바꾸거나 Hash 사용
- 대규모 - 대규모: Hash 사용. 처음부터 결합 키로 정렬이 되어 있는 상태라면 Sort Merge 사용

실행 계획 제어

RDB에서는 원칙적으로 통계 정보를 바탕으로 옵티마이저가 실행 계획을 자동으로 수립
실행 계획을 사용자가 제어할 때의 리스크
- 데이터 양과 카디널리티는 데이터베이스를 운용하는 동안 계속 바뀌므로 어떤 시점에는 적절했던 실행 계획이 또 다른 시점에는 적절하지 않을 수 있음
- 따라서, 사용자가 실행 계획을 제어할 때는 이러한 위험을 충분히 검토하고, 시스템의 미래 상황도 예측해서 적절한 실행 계획을 선택해야 함

흔들리는 실행 계획

데이터 양의 증가 등에 따라 통계 정보가 변했을 때 일정한 역치를 넘으면 ‘옵티마이저의 실패’가 발생할 수 있음
SQL 성능의 변동 위험을 줄이려면 되도록 결합을 피해야 함