Data analysis, Game, Diary

[데블챌 7일] INNER JOIN보다 WHERE IN 의 연산이 빠를까?


[데블챌 7일] INNER JOIN보다 WHERE IN 의 연산이 빠를까?


들어가며,

  • 데이터 블로그 챌린지(데블챌 2기) 7일차입니다.

  • 14일 간 블로그 게시글을 올리면서 글 쓰는 습관을 들여보려 합니다.



목차

  • INNER JOIN보다 WHERE IN 의 연산이 빠를까?





  • INNER JOIN보다 WHERE IN 의 연산이 빠를까?

당연하다고 여길 수 있지만 과거에 궁금했던 점을 검색해봤습니다.

(INNER JOIN ON) 필터링이 (WHERE IN) 필터링 연산보다 빠를까?'
-- INNER JOIN절 ON 필터링
SELECT * FROM table1
INNER JOIN table2 ON table1.column1 = table2.column2;
-- WHERE절 IN 서브쿼리 필터링
SELECT * FROM table1
WHERE column1 IN (SELECT column2 FROM table2);

로 풀어 쓸 수 있겠습니다. 일반적인 경우 논리 절차상 INNER JOIN이 빠르다고 생각했는데요.

왜 그런지 분명히 설명하려니 조금 막막해서 더 찾아봤습니다.

원문 페이지의 Stackoverflow의 질문은 조금 다른 맥락이긴 했지만 답변에서 답을 얻었습니다.


MS SQL SERVER 2005의 논리적 쿼리 단계


-- Reference: Inside Microsoft® SQL Server™ 2005 T-SQL Querying
-- Publisher: Microsoft Press
-- Pub Date: March 07, 2006
-- Print ISBN-10: 0-7356-2313-9
-- Print ISBN-13: 978-0-7356-2313-2
-- Pages: 640

(8)  SELECT (9) DISTINCT (11) TOP <top_specification> <select_list>
(1)  FROM <left_table>
(3)       <join_type> JOIN <right_table>
(2)       ON <join_condition>
(4)  WHERE <where_condition>
(5)  GROUP BY <group_by_list>
(6)  WITH {CUBE | ROLLUP}
(7)  HAVING <having_condition>
(10) ORDER BY <order_by_list>

[순서별 논리 단계]

FROM: FROM 절에 있는 첫 두 테이블 간의 카테시안 곱이 수행되어 (1) 가상 테이블이 생성되고,

ON: ON 필터가 (1)에 적용되어, 조인 조건이 TRUE인 행만 (2)에 삽입됩니다.

OUTER JOIN: OUTER JOIN이 지정된 경우, (2)의 행에 일치하는 행이 없는 테이블의 행(NULL)이 추가되어 (3)이 생성됩니다.

FROM 절에 두 개 이상의 테이블이 있는 경우, 마지막 조인의 결과와 다음 테이블 간에 1~3단계를 반복하여 모든 테이블을 처리합니다.

WHERE: WHERE 필터가 (3)에 적용되어, 조건이 TRUE인 행만 (4)에 삽입됩니다.


[요약]

‘대용량 데이터’를 처리할 때, WHERE 절의 서브쿼리가 먼저 실행되며 메모리에 올라가므로 데이터가 커질 때 연산에서 손해보는 상황이 생깁니다. 또한 INNER JOIN의 경우 테이블의 인덱스를 활용할 수 있다는 점에서 대용량 데이터를 처리하는데 더 효율적입니다.

물론 WHERE IN 형태의 필터링이 아니라 단순히 WHERE 조건문이라고 하면, INNER JOIN과 비교할 때 두 테이블의 카테시안 곱 결과를 필터링하므로 논리적으로는 동일한 결과를 내며 가독성이 좋은 쪽을 택한다고 합니다. 더 자세하게 들어가면 두 방식의 최적화에 따라 달라져서 완전히 동일하지는 않다고 하네요.

[한줄 인사이트]

HEAD FIRST SQL 이란 책으로 처음 SQL을 배웠을 때 나온 바보 같은 질문이란 없다고 했던 말이 생각났습니다. 꼼꼼하게 찾아보는 버릇을 들여야겠네요.

추가로 찾으면서 이해한 내용이 틀렸을 수 있으니 링크드인이나 인스타그램 통해 의견 주시면 감사하겠습니다.




Reference