NOT IN의 함정을 단순 암기하는지보다, NULL 의미론과 실행 계획을 근거로 NOT EXISTS·LEFT JOIN IS NULL 중 무엇을 언제 고르는지 판단할 수 있는지 가른다. "NOT EXISTS가 빠르다" 한 줄로 끝내는지, 데이터 분포까지 들고 가는지가 갈림길이다.
NOT IN은 "이 목록에 없는 행"을 찾는 부정 조건이다. 옵티마이저는 IN과 달리 부정 조건에서 인덱스를 anti-join으로 풀어내야 하고, 서브쿼리 결과에 NULL이 하나라도 섞이면 3값 논리 때문에 전체 결과가 비어 버린다. 그래서 실무에서는 NOT EXISTS나 LEFT JOIN ... IS NULL로 바꿔 NULL 안전성과 실행 계획을 동시에 챙기는 쪽으로 간다.
NULL이 섞인 서브쿼리 때문에 결과가 0건으로 빠지는 버그를 잡아본 적이 있다면, NOT IN의 3값 논리를 그 사건의 원인으로 설명할 수 있다
EXPLAIN을 보고 NOT IN을 NOT EXISTS로 바꿔 anti-join이 잡힌 경험이 있다면, 치환 전후 실행 계획 비교를 답변 골격으로 쓸 수 있다
LEFT JOIN IS NULL이 인덱스 덕에 더 빨랐던 경험이 있다면, NOT EXISTS와의 선택 기준을 데이터 분포·중복 행으로 풀어낼 수 있다
DBMS 마이그레이션이나 버전 업 이후 같은 쿼리가 느려진 경험이 있다면, 옵티마이저 차이를 검증하는 절차로 연결할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.