JOIN 점검 구조
좋은 JOIN은 관계를 맞추고, 읽는 양과 왕복 횟수를 함께 줄이는 일입니다
조인 문제는 따로따로 생기지 않습니다. 관계가 느슨하면 결과가 틀어지고, 범위가 넓으면 I/O가 커지며, 그 부담을 애플리케이션 쪽으로 미루면 N+1과 복잡한 조회 경로가 남습니다.
1. 관계 고정
`ON` 조건이 빠지면 결과 의미부터 깨집니다
실수 FROM users, orders
연결 기준이 없으면 원하는 매칭이 아니라 카테시안 곱이 되어 행 수가 불어나고, 이후 튜닝보다 먼저 결과 집합이 틀어집니다.
핵심 목표
JOIN 한 번으로 정확한 집합을 읽는다
아래 네 축은 서로 다른 팁이 아니라, 결국 같은 두 결과를 만들기 위한 점검 기준입니다.
정확한 결과 집합
관계 조건과 컬럼 출처가 분명해야 중복, 누락, 모호한 참조를 막을 수 있습니다.
낮은 읽기 비용
필요한 컬럼만 읽고, 필요한 연관 데이터도 한 번에 가져와야 I/O와 왕복이 줄어듭니다.
실무 감각: 조인이 계속 길어지면 인덱스만 추가하기보다
조회 경로와 스키마 경계를 먼저 다시 보아야 합니다.
3. 조회 횟수
N+1은 관계를 DB 밖에서 다시 따라가는 패턴입니다
나쁜 흐름 users 1회 → orders N회
좋은 흐름 JOIN 1회 또는 Eager Loading
연관 데이터를 나중에 개별 조회하면 같은 형태의 쿼리가 반복되어 네트워크 왕복과 대기 시간이 커집니다.
2. 읽기 범위
별칭과 필요한 컬럼만 남기면 해석과 I/O가 동시에 가벼워집니다
SELECT u.name, o.order_id vs SELECT *
같은 이름의 컬럼 충돌을 줄이고, 필요 없는 데이터까지 읽는 일을 막아 결과 해석과 전송량을 함께 줄입니다.
4. 구조 신호
반복해서 많은 테이블을 묶는다면 쿼리보다 설계를 의심해야 합니다
5개 이상 조인이 자주 등장
조회가 복잡해졌다는 뜻입니다. VIEW, 스키마 분리, 조회 전용 구조를 검토할 시점일 수 있습니다.
복잡도를 한 줄 SQL로 버티기 시작하면 튜닝 포인트보다 변경 영향과 운영 난이도가 먼저 커집니다.
ON 조건
관계가 맞는지 먼저 확인
컬럼 범위
별칭과 필요한 컬럼만 선택
조회 횟수
한 번에 읽지 못해 N+1이 생기지 않는지
스키마 경계
조인이 과하면 구조 자체를 재검토