[SQL] Join vs Sub-query, sharding

코딩테스트를 볼 때 Join을 사용해야 하는 문제가 나와도 Sub-query로 작성하는게 더 편해서 서브쿼리를 작성해왔다. 검색해보니 많은 사람(특히 SQL입문자)들이 서브쿼리가 조인에 비해 작성하기 쉬워 선호한다고 한다.

그런데 작성하기 쉬운건 쉬운거고, 성능이 문제다. 대부분의 경우 조인이 서브쿼리에 비해 성능이 좋다. 

 

가독성: Sub-query>Join

성능: Join>Sub-query

 

다행히도 MySQL 5.6 버전부터는 서브쿼리가 많이 최적화되었다고 한다. 그러나 최적화가 적용되지 않는 조건들이 다수 존재한다고 하니 웬만하면 조인을 사용하는게 좋다.

 

[조인이 서브쿼리보다 성능이 좋은 이유]

In JOINs RDBMS can create an execution plan that is better for your query and can predict what data should be loaded to be processed and save time, unlike the sub-query where it will run all the queries and load all their data to do the processing. - [참고]-3 Kronass, htoip

서브쿼리 - 모든 쿼리를 실행하고 모든 데이터를로드하여 처리를 수행

조인 - 처리 할 데이터를 예측 → 시간 절약

 

[조인이 느리다는 말이 있던데...]

과거에는 조인이 느리니까 사용하지 말라는 사람들이 꽤 있었다고 한다. 그런데 그건 워낙 과거의 일이고 요즘은 그런 경우가 잘 없다고 한다. 

조인이 느리다는건 SQL문을 효율적으로 작성하지 못해서, 본래의 성능을 내고 있기 때문이다.

 

지금도 조인을 사용하지 말자고 하는 경우는 모든 개발자가 빠르고 정확한 SQL문을 작성할 수 있는건 아니니까, 최대한 간단히 작성하자는 의미일 것이라고 생각한다.  하지만 조인이면 한번이면 끝날 것을 SELECT문을 반복해서 하게 된다면 상당히 효율이 떨어질 것이다. 

 

왜냐면 애플리케이션은 보통 데이터베이스 서버와 다른 컴퓨터에서 작동하니, 데이터베이스에 원격 접속을 하는게 된다. 원격 접속은 리소스를 많이 사용하므로(네트워크, 서버 부하) 최대한 줄일 수 있다면 줄이는게 좋다. 

 

+ SQL문(쿼리) 성능 측정 방법 : EXPLAIN

 

 

[분산 데이터베이스 환경(샤딩)]

대규모 애플리케이션에서는 특정 테이블의 트래픽이 너무 커서 한 개의 서버에서 처리를 하지 못하는 경우가 있고, 이러한 경우에 테이블 단위 또는 하나의 테이블을 여러 서버에 분산을 하는 경우가 있고 이를 샤딩이라고 한다고 한다. 

 

샤딩을 하고 있다면 결합 대상 테이블이 같은 서버에 있다는 걸 장담할 수 없어서 조인을 사용하기가 어렵다. 그래서 애플리케이션의 규모가 커질 것이 예상된다면 샤딩의 필요성을 처음부터 염두에 두고 애플리케이션을 만든다고 한다. 

 

 

[참고]

1. 서브쿼리와 조인 성능 비교, 서브쿼리 최적화가 적용되는 경우(티스토리 링크)

MySQL where in (서브쿼리) vs 조인 조회 성능 비교 (5.5 vs 5.6)

2. 서브쿼리를 조인으로 재작성하는 방법(MySQL Document Link)

MySQL :: MySQL 5.7 Reference Manual :: 13.2.10.11 Rewriting Subqueries as Joins

3. Join vs sub-query(Stackoverflow link)

Join vs. sub-query