답변.

문제의 역사:

EXISTS 및 IN 연산자는 서브쿼리를 기반으로 레코드를 필터링하는 데 사용됩니다. SQL이 처음 도입된 이래로 개발자들은 그들 사이에서 선택해야 했으며, 어떤 방법이 더 빠르고 어떤 경우에 이들을 사용하는 것이 더 바람직한지 이해하려고 했습니다.

문제:

주요 과제는 외부 또는 내부 테이블에서 일치하는 행만 선택하는 것입니다. 이는 대량의 데이터 세트에 대한 성능에 항상 중요한 요소입니다. EXISTS와 IN 중 하나를 선택하는 것은 서브쿼리의 구조, 반환되는 값의 수와 고유성, 사용되는 DBMS에 따라 달라집니다.

해결책:

IN은 서브쿼리가 적은 수의 고유한 값을 반환할 때 보통 더 효율적입니다.
EXISTS는 일치하는 행의 존재 여부만 중요할 경우 더 선호되며, 수천 또는 수백만 개의 행을 반환하는 큰 서브쿼리에 적합합니다.
NULL과 관련된 특정 동작 및 다양한 데이터베이스 관리 시스템에서의 최적화 차이에 대해 기억해야 합니다.

코드 예시:

-- IN 사용
SELECT name FROM students WHERE id IN (SELECT student_id FROM enrollments WHERE course = 'SQL');

-- EXISTS 사용
SELECT name FROM students WHERE EXISTS (SELECT 1 FROM enrollments WHERE enrollments.student_id = students.id AND enrollments.course = 'SQL');

주요 특징:

EXISTS는 첫 번째 일치 시 검색을 종료합니다(내장된 서브쿼리가 중단될 수 있습니다).
IN은 일반적으로 짧은 목록에 대해 효율적이지만, 길고 비고유한 서브쿼리에서는 느릴 수 있습니다.
EXISTS는 NULL이 있을 때 올바르게 작동하며, IN은 서브쿼리에서 NULL이 있을 때 예기치 않게 동작할 수 있습니다.

함정 질문.

서브쿼리 IN에서 NULL이 있을 경우 어떻게 됩니까?

많은 사람들은 IN이 NULL을 단순히 무시할 것이라고 생각하지만, NULL이 존재할 경우 결과는 예측할 수 없게 될 수 있습니다. 예를 들어, 쿼리:

SELECT id FROM orders WHERE client_id IN (1, NULL, 2);

기술적으로 client_id가 1 또는 2가 아닌 행은 포함되지 않지만, 만약 서브쿼리 목록에 NULL만 포함된다면 결과는 빈 값이 됩니다.

EXISTS와 IN은 완전히 상호 교환 가능한 구조입니까?

아닙니다. EXISTS 사용이 종종 더 빠릅니다. 왜냐하면 전체 서브쿼리를 분석할 필요가 없기 때문입니다. 또한 IN은 다수의 열로 구성된 서브쿼리에서 작동하지 않지만 EXISTS는 작동합니다. 이는 WHERE 조건으로 비교하기 때문입니다. 예를 들어:

SELECT col1 FROM t1 WHERE (col1, col2) IN (SELECT col3, col4 FROM t2);

이 방법은 종종 지원되지 않지만, 유사한 EXISTS는 지원됩니다.

IN이 인덱스된 필드에서 EXISTS보다 더 빠르게 작동할 수 있습니까?

네, 서브쿼리가 작고 비교되는 필드에 인덱스가 있을 경우 IN이 더 빠를 수 있습니다. 그러나 큰 선택 세트나 인덱스가 없을 경우는 반대입니다.

일반적인 오류 및 안티패턴

많은 양의 행을 반환하는 서브쿼리와 함께 IN 사용.
서브쿼리에서 NULL의 존재 결과를 무시.
기본적으로 모든 경우에 대해 EXISTS를 IN으로 대체하는 것.

실제 사례

부정적 케이스

분석가가 IN 방법으로 보고서를 작성했으나, 서브쿼리가 수십만 개의 NULL 행을 반환한다는 점을 간과했습니다. 보고서는 여러 분 동안 작동하며 데이터 손실이 발생했습니다.

장점:

이해하기 쉬운 논리 단점:
성능 저하
잘못된 데이터 수집 위험

긍정적 케이스

같은 쿼리를 EXISTS로 재작성하고 추가 조건을 포함하며 인덱스를 재계산했습니다.