177. 뷰 머징 (View Merging)

핵심 인사이트: 개발자가 작성한 SQL의 '인라인 뷰(서브쿼리)'를 그대로 실행하면 비효율적인 경우가 많다. 똑똑한 옵티마이저는 뷰의 껍데기를 확 벗겨버리고, 메인 쿼리와 한 덩어리로 병합(Merge)하여 조인 순서를 자유롭게 재배치하는 최적화 마술을 부린다. 이것이 뷰 머징이다.

Ⅰ. 뷰 머징(View Merging)의 개념

복잡한 쿼리 작성 시 가독성을 위해 생성된 뷰(View) 나 쿼리 내부에 작성된 인라인 뷰(Inline View, FROM 절의 서브쿼리) 를, 비용 기반 옵티마이저(CBO)가 내부적으로 해체하여 메인 쿼리와 하나의 쿼리로 병합(Merging) 하는 쿼리 변환(Query Transformation) 기술입니다.

Ⅱ. 뷰 머징의 동작 과정

[ 개발자가 작성한 쿼리 (뷰 사용) ]
SELECT A.부서명, V.사원명
  FROM 부서 A,
       (SELECT 부서번호, 사원명 FROM 사원 WHERE 급여 > 5000) V -- ◀ 인라인 뷰
 WHERE A.부서번호 = V.부서번호;

            ▼ (옵티마이저의 뷰 머징 변환) ▼

[ 옵티마이저가 내부적으로 실행하는 쿼리 (뷰 해체) ]
SELECT A.부서명, B.사원명
  FROM 부서 A, 사원 B  -- ◀ 뷰의 껍데기가 사라지고 메인 테이블로 올라옴
 WHERE A.부서번호 = B.부서번호
   AND B.급여 > 5000;

Ⅲ. 뷰 머징을 하는 이유 (효과)

만약 뷰 머징을 하지 않으면 옵티마이저는 반드시 뷰 내부의 쿼리를 먼저 독자적으로 실행(뷰 독립 실행)하여 임시 결과를 만들어야 합니다. 하지만 뷰를 메인 쿼리와 병합(Merge)해버리면, 옵티마이저가 전체 테이블을 통틀어 '조인 순서(Join Order)' 를 자유롭게 바꾸고, 가장 효율적인 '드라이빙 테이블(Driving Table)' 을 선택할 수 있는 폭(Search Space)이 훨씬 넓어지기 때문에 성능이 극적으로 향상됩니다.

Ⅳ. 뷰 머징이 불가능한 경우 (View Merging 제약 조건)

옵티마이저가 항상 뷰 머징을 할 수 있는 것은 아닙니다. 뷰 내부에 결과 집합의 형태를 바꿔버리는 특수한 연산자가 포함된 경우, 함부로 껍데기를 벗길 수 없어 머징을 포기하고 뷰를 독립적으로 실행하게 됩니다.

• 뷰 내부에 GROUP BY 구문이나 그룹 함수(SUM, AVG 등)가 있는 경우
• 뷰 내부에 DISTINCT가 있는 경우
• 뷰 내부에 집합 연산자 (UNION, INTERSECT, MINUS)가 있는 경우
• 뷰 내부에 분석 함수 (ROW_NUMBER, RANK 등)가 있는 경우

📢 섹션 요약 비유: 요리사가 레시피(개발자 쿼리)에 "1번 냄비에 소스를 끓여두고, 2번 프라이팬에 고기를 굽다가 나중에 합쳐라"라고 써놨지만, 똑똑한 주방장(옵티마이저)이 "그렇게 하면 설거지만 늘어나! 그냥 커다란 웍(메인 쿼리) 하나에 다 때려 넣고 한 번에 볶자!(뷰 머징)"라며 요리 방식을 최적화하는 것과 같습니다.