옵티마이저 이해하기 - 1

SQL의 구문분석 절차

1. 동일한 SQL의 수행여부 확인

2. 문법/절차 확인

3. SEMANTIC확인

4. 권한 확인

1. 동일한 SQL의 수행여부확인

 - Soft Parsing : 동일한 SQL이 이전에 수행되었고, 실행계획등의 실행정보가 메모리에 저장되어있다.

 - Hard Parsing : 실행정보가 존재하지않아 구문 분석을 새로 시작해야한다.

2. 문법/ 절차 확인

 - 문법이 맞는지 확인. 틀리면 SYNTAX 에러 메시지 발생

3. SEMANTIC

 - Database Resolution단계, SQL에 사용된 테이블과 테이블 컬럼이 실제 DB에 존재하는지 확인

4. 권한 확인

  - 해당 SQL을 실행 할수 있는지 권한 확인

Query Transformation

- 구문 분석을 수행하는 중간단계에서 SQL을 변경하는 단계(Query Transformation)가 발생

- 옵티마이저가 단독으로 수행하는 과정

- 결과적으로 Query Tranformation은 처리범위를 감소시키는 조건을 찾아내어 처리범위를 감소시키는(SQL의 성능을 최적화 하기위한) 옵티마이저의 노력

- Transitivity

- View Merging

- Sub query Merging

- Or Expansion

- Query Rewrite

Transitivity

- 논리적으로 이상이 없는 조건을 추가하여 처리범위를 감소시켜 성능을 최적화 하고자 하는 옵티마이저의 노력

- WHERE절에 존재하는 A테이블의 상수 조건에 대해 논리적으로 타당하다면 B테이블에도 해당 상수 조건을 옵티마이저가 추가시켜 주는것

특징

- 점(=) 조건은 가능

- 선분 조건은 불가능

- 조인 조건은 불가능

View Merging

- 말그대로 뷰가 머징되는것

- Query Transformation에서 중요요소이다

- 뷰머징은 말로 표현하기 힘들정도로 심하게 발생한다.

- 인라인뷰는 주 쿼리의 조건을 받으므로, 처리범위를 더욱 감소시킬수 있게된다. 물론 인라인뷰의 추가된 조건이 해당 테이블의 인덱스로 걸려있어야만 처리범위가 감소하게 된다.

View Merging 종류

- 주 쿼리의 조건(WHERE)이 인라인 뷰 안으로 삽인 되는 뷰 머징

- 인라인 뷰 또는 뷰의 SQL이 주 쿼리로 합쳐지는 뷰머징

인라인뷰

인라인 뷰에서 괄호는 표현한부분 부터 연산을 수행하는 수학적인 괄호가 아니다. 단지 문법적인 구분의 역할만을 수행하게 된다. 그렇기 때문에 괄호를 사용하는 인라인 뷰는 언제든 변할 수있게 된다.

인라인뷰의 종류

- Mergeable 인라인 뷰 : 뷰가 해체되거나 뷰 안으로 조건이 삽입되는 인라인 뷰

- 주 쿼리의 조건(WHERE)이 인라인 뷰 안으로 삽인 되는 뷰

- 인라인 뷰 또는 뷰의 SQL이 주 쿼리로 합쳐지는 뷰

- Non-Mergeable인라인 뷰 : 뷰가 수학의 괄호처럼 별도로 수행되는 뷰

Non-Mergeable인라인 뷰확인하기

- UNION ALL

- UNION

- DISTINCT

- GROUP BY

- ROWNUM

- 집합 함수

Non-Mergeable 인라인뷰가 될 가능성이 높다.

완벽하게 확인하기 위해서는 SQL의 실행계획을 확인해보아야 한다.