SQL 기초 4 - JOIN 정리

1. 개요

JOIN 은 매번 어떤 걸 써야 하는지 헷갈린다. 특히 LEFT 와 RIGHT 는 왼쪽/오른쪽만 바꿔 쓰면 되는데도 매번 다시 생각하게 된다. 이번 글은 네 가지 JOIN 의 차이를 정리하고, 실행계획에서 옵티마이저가 테이블을 어떤 순서로 도는지 감을 잡아본다.

---

2. 핵심 내용

2-1. INNER JOIN — 양쪽에 다 있는 것만

SELECT u.name, o.id
FROM users u
INNER JOIN orders o ON u.id = o.user_id;

users 와 orders 양쪽에 조인 조건을 만족하는 행이 있을 때만 결과에 나온다. 주문이 없는 사용자는 결과에서 빠진다.

2-2. LEFT JOIN — 왼쪽은 다 살리고 오른쪽은 맞으면 붙인다

SELECT u.name, o.id
FROM users u
LEFT JOIN orders o ON u.id = o.user_id;

왼쪽 테이블(users)의 행은 조인 조건을 만족하든 안 하든 전부 남는다. 맞는 orders 행이 없으면 그 컬럼은 NULL 로 채워진다. “사용자별 주문 건수를 보고 싶은데 주문이 0건인 사용자도 0으로 보고 싶다” 같은 상황에 쓴다. RIGHT JOIN 은 반대로 오른쪽 테이블을 다 살리는 것뿐이라, 테이블 순서만 바꾸면 LEFT JOIN 으로 항상 똑같이 표현할 수 있다. 그래서 실무에서 RIGHT JOIN 을 직접 쓰는 경우는 드물다.

2-3. FULL JOIN — 양쪽 다 살린다

SELECT u.name, o.id
FROM users u
FULL JOIN orders o ON u.id = o.user_id;

양쪽 중 어느 한쪽에만 있어도 결과에 남고, 맞는 쪽이 없으면 그 자리는 NULL 이다. 두 집합의 차이를 찾을 때(예: 이쪽에는 있는데 저쪽에는 없는 데이터 찾기) 자주 쓴다. MySQL 은 FULL JOIN 을 지원하지 않아서 LEFT JOIN 과 RIGHT JOIN 결과를 UNION 으로 합쳐 흉내 내야 한다.

2-4. 옵티마이저는 어떤 순서로 도나

JOIN 을 작성한 순서와 실제로 옵티마이저가 테이블을 도는 순서는 다를 수 있다. EXPLAIN 을 찍어보면 옵티마이저가 고른 조인 방식이 나온다. 감만 잡아두면 실행계획을 읽을 때 도움이 된다.

• Nested Loop Join: 한쪽 테이블(주로 행이 적은 쪽, 드라이빙 테이블)을 순회하면서 각 행마다 다른 쪽 테이블에서 조인 조건에 맞는 행을 찾는다. 다른 쪽 테이블의 조인 컬럼에 인덱스 가 있으면 매우 빠르다. 인덱스가 없으면 안쪽 루프마다 풀스캔이 반복돼 비용이 급격히 커진다.
• Hash Join: 작은 쪽 테이블로 해시 테이블을 메모리에 만들고, 큰 쪽 테이블을 한 번 훑으면서 해시로 매칭한다. 인덱스가 없어도 쓸 수 있고, 대량 데이터를 한 번에 조인할 때 유리하다.
• Merge Join: 양쪽 테이블이 조인 키 기준으로 이미 정렬돼 있으면(또는 정렬 비용을 감수하고) 두 개의 정렬된 목록을 지퍼처럼 맞물려 가며 합친다.

옵티마이저는 테이블 통계(행 수, 카디널리티)를 보고 이 중 뭐가 쌀지 판단한다. 그래서 같은 쿼리라도 데이터가 쌓이면서 실행 계획이 Nested Loop 에서 Hash Join 으로 바뀌는 경우가 흔하다. 통계가 오래돼(ANALYZE 를 안 돌려서) 옵티마이저가 잘못 판단하는 경우도 실무에서 자주 본다.

---

3. 마무리

요약

• INNER JOIN 은 양쪽 다 맞는 것만, LEFT/RIGHT JOIN 은 한쪽을 전부 살리고 나머지는 NULL, FULL JOIN 은 양쪽 다 살린다.
• RIGHT JOIN 은 테이블 순서만 바꾸면 LEFT JOIN 으로 항상 표현 가능해서 실무에서 잘 안 쓴다.
• 옵티마이저는 작성 순서가 아니라 통계를 보고 조인 순서와 방식(Nested Loop/Hash/Merge)을 고른다.
• 통계가 오래되면 옵티마이저가 잘못된 실행계획을 고를 수 있다.

다음은 윈도우 함수 이다.

---