서브쿼리 비교

같은 결과여도
DB가 읽는 순서는 다릅니다

두 쿼리는 모두 “주문한 적 있는 사용자”를 찾을 수 있지만, EXISTS는 존재 확인에 맞춰 움직이고 IN은 비교할 집합을 먼저 준비합니다.

공통 목표

users 중에서 orders에 같은 user_id가 하나라도 있는 행만 반환

EXISTS: users의 각 행에 대해 orders를 바로 확인 IN: orders에서 user_id 목록을 먼저 만든 뒤 users와 비교
핵심: 반환 결과는 같아질 수 있어도, 어디까지 읽고 언제 멈추는지가 달라집니다.
EXISTS

외부 행을 보다가
첫 일치에서 바로 멈춤

존재 여부만 확인하면 충분할 때 자연스럽습니다.

1
users의 현재 행을 기준으로 orders를 확인

외부 행 하나를 잡고, 그 user_id와 맞는 주문이 있는지 찾습니다.

2
일치하는 주문 1건을 찾는 순간 TRUE

더 많은 주문 행을 끝까지 모을 필요 없이 조건이 이미 만족됩니다.

3
다음 users 행으로 바로 이동

큰 내부 테이블에서도 “있다 / 없다”만 빠르게 판정하는 흐름입니다.

IN

서브쿼리 결과를 만든 뒤
그 집합에 포함되는지 비교

비교 대상 집합을 먼저 확보하는 방식으로 읽힙니다.

1
먼저 orders에서 user_id 결과 집합 생성

서브쿼리가 반환할 값들을 한 번 구해 두고 비교 준비를 합니다.

2
준비된 집합과 users를 대조

각 사용자 행의 user_id가 그 집합 안에 있는지 확인합니다.

3
멈춤 기준은 “첫 일치”가 아니라 “집합 준비 완료”

그래서 서브쿼리 쪽을 먼저 끝까지 계산하는 성격이 더 강합니다.

읽기 방식 차이

EXISTS는 외부 행마다 즉시 확인하고, IN은 내부 결과를 먼저 정리한 뒤 비교합니다.

학습 포인트

이 슬롯에서 기억할 것은 문법 차이보다도 Short-circuit 여부와 서브쿼리 평가 순서입니다.