7장 서브쿼리

21. 서브쿼리가 일으키는 폐해

- 서브쿼리란 SQL 내부에서 작성되는 일시적인 테이블이다

- SQL은 테이블과 서브쿼리를 같은 것 취급한다. ( 기능적인 관점에서 )

- 테이블, 뷰, 서브쿼리의 차이점

    ㆍ테이블 : 영속적인 데이터를 저장

    ㆍ뷰 : 영속적이지만 데이터는 저장하지 않음, 따라서 접근할 때마다 SELECT 구문이 실행됨

    ㆍ서브쿼리 : 비영속적인 생존 기간(스코프)이 SQL 구문 실행 중으로 한정

 

1. 서브쿼리의 문제점

- 서브쿼리의 성능적 문제는 결과적으로 서브쿼리가 실체적인 데이터를 저장하고 있지 않다는 점에서 기인한다.

 

연산 비용 추가

- 실체적인 데이터를 저장하고 있지 않다는 것은 서브쿼리에 접근할 때마다 SELECT 구문을 실행해서 데이터를 만들어야 한다는 뜻이다

- 따라서 SELECT 구문 실행에 발생하는 비용이 추가된다.

 

데이터 I/O 비용 발생

- 연산 결과는 어딘가에 저장하기 위해 써두어야 한다.

- 메모리 용량이 충분하다면 이러한 오버헤드가 적지만, 데이터양이 큰 경우등에는 DBMS가 저장소에 있는 파일에 결과를 쓸 떄도 있다.

- TEMP 탈락 현상의 일종이라고 말할 수 있는데, 이렇게 되면 저장소 성능에 따라 접근 속도가 급격하게 떨어진다.

 

최적화를 받을 수 없음

- 서브쿼리로 만들어지는 데이터는 구조적으로 테이블과 차이가 없다.

- 하지만 명시적인 제약 또는 인덱스가 작성되어 있는 테이블과 달리, 서브쿼리에는 그러한 메타 정보가 하나도 존재하지 않는다.

    ㆍ따라서 옵티마이저가 쿼리를 해석하기 위해 필요한 정보를 서브쿼리에서 얻을 수 없다.

 

2. 서브쿼리 의존성

서브쿼리의 단점

- 1. 코드가 복잡해서 읽기 어렵다

- 2. 성능

    ㆍ1. 서브쿼리는 대부분 일시적인 영역(메모리 또는 디스크)에 확보되므로 오버헤드가 생긴다.

    ㆍ2. 서브쿼리는 인덱스 또는 제약 정보를 가지지 않기 때문에 최적화되지 못한다.

    ㆍ3. 이 쿼리는 결합을 필요로 하기 때문에 비용이 높고 실행 계획 변동 리스크가 발생한다.

    ㆍ4. 테이블에 스캔이 두 번 필요하다.

 

3. 장기적 관점에서의 리스크 관리

- 옵티마이저가 이해하기 쉽게 쿼리를 단순하게 작성해야 한다.

 

- 실행 계획이 단순할수록 성능이 안정적이다.

- 엔지니어는 기능(결과)뿐만 아니라 비기능적인 부분(성능)도 보장할 책임이 있다.

 

4. 서브쿼리 의존증 - 응용편

5. 서브쿼리는 정말 나쁠까?

- 서브쿼리 자체가 나쁜 것이 아니다.

- 게다가 서브쿼리를 사용하지 않으면 해결할 수 없는 상황도 많다.

 

---

22. 서브쿼리 사용이 더 나은 경우

- 서브쿼리를 사용하는 편이 성능 측면에서 더 나은 경우

    ㆍ결합과 관련된 쿼리 - 결합할 때는 최대한 결합 대상 레코드 수를 줄이는 것이 중요하다.

 

1. 결합과 집약 순서

- 결합 대상 레코드 수를 집약하는 편이 I/O 비용을 더 줄일 수 있다.

- 튜닝 선택지 중 하나로 '사전에 결합 레코드 수를 압축한다' 라는 방법이 있다.

 

---

마치며..

- 서브쿼리는 복잡한 문제를 분할할 수 있는 편리한 도구지만, 결합을 늘리는 성능 악화를 일으킬 수 있음

- SQL 성능을 결정하는 요인은 I/O가 절대적

- 서브쿼리와 결합을 원드우 함수로 대체하면 성능을 개선할 가능성이 있음

- 서브쿼리를 사용할때는 결합 대상 레코드 수를 사전에 압축해서 성능을 개선할 수 있음