7. 서브쿼리(곤란한 부분은 분할해야만 할까?)

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

1) 서브쿼리의 문제점

• 성능적 문제는 서브쿼리가 실체적인 데이터를 저장하고 있지 않다는 것에 있다.

(1) 연산 비용 추가

• 서브쿼리 = SELECT 이므로 실행할때마다 SELECT 하는 것

(2) 데이터 I/O 비용 발생

• 연살결과가 커 저장소를 쓰게 되는 경우 급격한 속도 저하 발생

(3) 최적화를 받을 수 없음

• 서브쿼리의 결과에는 메타 정보가 없어 최적화가 불가능

2) 서브쿼리 의존증

(1) 서브쿼리를 사용한 방법

• 코드가 복잡해 읽기 어렵다
• 성능
  • 결과가 일시적인 영역에 확보되므로 오버헤드 발생
  • 최적화 불가
  • 결합을 필요로 하기 때문에 비용이 높고 실행계획 변동 리스크가 존재
  • recipts 테이블 두번 스캔 필요

(2) 상관 서브쿼리는 답이 될 수 없다

• 어쨋든 테이블에 2번 접근해야 한다

(3) 윈도우 함수로 결합 해결

• 목표는 테이블 접근 1회로 줄이기
• ROW_NUMBER를 사용해 구매 이력 번호를 붙이고, 이력이 1인 레코드 추출

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

• 결합을 사용한 쿼리의 불안정 요소(상관 서브쿼리도 유사)
  • 결합 알고리즘의 변동 리스크
  • 환경 요인에 의한 지연 리스크(인덱스, 메모리, 매개변수 등)

(1) 알고리즘 변동리스크

• 상황에 따라 변하는 결합 알고리즘

(2) 환경 요인에 의한 지연 리스크

• 결합을 사용한다는 것 = 장기적인 관점에서의 리스크 증가

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

(1) 다시 서브쿼리 의존증

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

• 생각하기는 쉬우나 RDB와는 맞지 않다

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

• 결합쿼리는 최대한 결합 대상 레코드수를 줄이는 것이 중요한데, 옵티마이저가 잘 판단하지 못하는 경우 직접 연산 순서를 명시하는 용도로 힌트 사용

1) 결합과 집약 순서

(1) 두 가지 방법

• 1. 결합 -> 집약
• 2. 집약 -> 결합

(2) 결합 대상의 레코드 수

• 2의 경우 레코드수가 줄기 때문에 더 나은 선택일 수 있다(사전에 결합 레코드수 압축)