SQL 최적화 기본 원리] 옵티마이저와 실행계획

제 1 절 옵티마이저와 실행계획

 

1. 옵티마이저(Optimizer)

 

1)  옵티마이저는 사용자가 질의한 SQL문에 대해 최적의 실행 방법을 결정하는 역할을 수행

2) 최적의 실행 방법을 실행계획(Execution Plan)이라고 함.

3) 다양한 실행 방법들 중에서 최적의 실행 방법을 결정하는 것이 옵티마이저의 역할임.

4) 관계형 데이터베이스는 옵티마이저가 결정한 실행 방법대로 실행 엔진이 데이터를 처리하여 결과 데이터를 사용자에게 전달

5) 옵티마이저가 선택한 실행 방법의 적절성 여부는 질의의 수행 속도에 가장 큰 영향을 미치게 됨. > 최적의 실행 방법 결정이라는 것은 어떤 방법으로 처리하는 것이 최소 일량으로 동일한 일을 처리할 수 있을지 결정하는 것

6) 옵티마이저가 최적의 실행 방법을 결정하는 방식에 따라 규칙기반 옵티마이저(RBO, Rule Based Optimizer)/ 비용기반 옵티마이저(CBO, Cost Based Optimizer)로 구분

 

▲ 참고. 파서란? 컴파일러나 인터프리터에서 원시 프로그램을 읽어 들여, 그 문장의 구조를 알아내는 구문 분석(parsing)을 행하는 것

위 그림에서 딕셔너리 -통계-> 비용기반 옵티마이저 부분: 비용기반 사용 시 데이터 딕셔너리에 저장된 다양한 통계 정보를 이용하여 비용 예측

 

- 현재 대부분의 관계형 데이터베이스는 비용기반 옵티마이저만을 제공

- 규칙기반 옵티마이저를 제공하더라도 신규 기능들에 대해서는 더 이상 지원하지 않음 > 하위 버전 호환성을 위해서만 규칙기반 옵티마이저가 남아있음.

- 어쨌든 규칙기반 옵티마이저의 규칙은 보편 타당성에 근거한 것들이기 때문에 규칙을 알고 있는 것이 옵티마이저의 최적화 작업을 이해하는데 좋음.

 

가. 규칙기반 옵티마이저(현재 하위버전 호환성을 위해서만 제공)

 

ㄱ) 규칙(우선 순위)을 가지고 실행계획을 생성

ㄴ) 규칙기반 옵티마이저가 실행계획을 생성할 때 참조하는 정보

 - SQL문을 실행하기 위해서 이용 가능한 인덱스 유무(유일, 비유일, 단일, 복합 인덱스) 종류

 - SQL문에서 사용하는 연산자 (=, <, <>, LIKE, BETWWEN 등)의 종류

 - SQL문에서 참조하는 객체(힙 테이블, 클러스트 테이블)의 종류 등참고)- 힙 테이블: http://wiki.gurubee.net/pages/viewpage.action?pageId=28117320- 클러스트 테이블 : http://playdata.io/2017/09/24/1-3-1-clustering/ㄷ) 참조하는 정보에 따라 우선 순위(규칙)이 정해져 있고, 이 우선 순위를 기반으로 실행계획을 생성

▲ 순위의 숫자가 낮을수록 우선 순위임.

 

ㄹ) 규칙기반 옵티마이저 규칙 중 주요한 규칙들

 

규칙1. Single row by rowid : rowid를 통해서 테이블에서 하나의 행을 액세스 하는 방식 > rowid는 행이 포함된 데이터 파일, 블록 등의 정보를 가지고 있기 때문에 다른 정보를 참조하지 않고도 바로 원하는 행을 액세스 할 수 있음 > 하나의 행을 액세스하는 가장 빠른 방법

 

규칙4. Single row by unique or primary key : 유일 인덱스(Unique Index)를 통해서 하나의 행을 액세스하는 방식 > 이 방식은 인덱스를 먼저 액세스하고 인덱스에 존재하는 rowid를 추출하여 테이블의 행을 액세스 함.

 

규칙8. Composite Index : 복합 인덱스에 동등('=' 연산자) 조건으로 검색하는 경우

예를 들어, 만약 a+b 컬럼으로 복합 인덱스가 생성되어 있고, 조건절에서 where a = 10 and b = 1 형태로 검색하는 방식임.

복합 인덱스 사이의 우선 순위 규칙

- 인덱스 구성 컬럼의 개수가 더 많고 해당 인덱스의 모든 구성 컬럼에 대해 '='로 값이 주어질 수록 우선순위가 더 높음. 

- 예를 들어, a+b로 구성된 인덱스와 a+b+c로 구성된 인덱스가 각각 존재하고 조건절에서 a, b, c컬럼 모두에 대해 '='로 값이 주어진다면 a, b, c 인덱스가 우선 순위가 높음.- 만약 조건절에서 a, b 컬럼에만 '='로 값이 주어진다면 a+b는 인덱스의 모든 구성 컬럼에 대해 값이 주어지고 a+b+c 인덱스 입장에서는 인덱스의 일부 컬럼에 대해서만 값이 주어졌기 때문에 a+b 인덱스가 우선 순위가 높게 됨.
규칙9. Single column index : 단일 컬럼 인덱스에 '=' 조건으로 검색하는 경우 > 만약 a 컬럼에 단일 컬럼 인덱스가 생성되어 있고, 조건절에서 a=10형태고 검색하는 방식
규칙 10. Bounded range search on indexed columns: 인덱스가 생성되어 있는 컬럼에 양쪽 범위를 한정하는 형태로 검색하는 방식 > between, like 등- 만약 a컬럼에 인덱스가 생성되어 있고, a between '10' and '20' 또는 a like '1%' 형태로 검색하는 방식
규칙 11. Unbounded range serach on indexed columns: 인덱스가 생성되어 있는 컬럼에 한쪽 범위만 한정하는 형태로 검색하는 방식 > 

 '>, >=, <, <= '등

- a 컬럼에 인덱스가 생성되어 있고, a > '10' 또는 a < '20' 형태로 검색하는 방식
규칙 15. full table scan : 전체 테이블을 액세스하면서 조건절에 주어진 조건을 만족하는 행만을 결과로 추출
ㅁ) 규칙기반 옵티마이저는 인덱스를 이용한 액세스 방식이 전체 테이블 액세스 방식보다 우선 순위가 높음. > 따라서 규칙기반 옵티마이저는 해당 sql문에서 이용 가능한 인덱스가 존재한다면 전체 테이블 액세스 방식보다는 항상 인덱스를 사용하는 실행계획을 생성

- 조인 순서 결정 : 조인 컬럼 인덱스의 존재 유무가 판단 기준

- 조인 컬럼에 대한 인덱스가 양쪽 테이블에 존재 : 규칙에 따라 우선 순위가 높은 테이블을 선행 테이블(Driving Table)로 선택

- 한쪽 조인 컬럼에만 인덱스가 존재하는 경우 : 인덱스가 없는 테이블을 선행 테이블로 선택해서 조인을 수행

- 조인 컬럼에 모두 인덱스가 존재하지 않는 경우 : from 절의 뒤에 나열된 테이블을 선행 테이블로 선택

- 조인 테이블의 우선 순위가 동일한 경우 : from 절에 나열된 테이블의 역순으로 선행 테이블을 선택

- 양쪽 조인 컬럼에 모두 인덱스가 없는 경우 : sort merge join을 사용하고 둘 중 하나라도 조인 컬럼에 인덱스가 존재한다면 일반적으로 NL join을 사용

참고) NL JOIN : http://wiki.gurubee.net/pages/viewpage.action?pageId=26744589

 

ㅂ) 옵티마이저의 최적화 과정

SELECT      ENAME FROM EMP WHERE JOB = 'SALESMAN'     AND  SAL BETWEEN 3000 AND 6000 INDEX ----------------------------------------- EMP_JOB : JOB EMP_SAL : SAL PK_EMP : EMPNO (UNIQUE)

▲ 조건절에서 JOB 컬럼의 조건은 '=', SAL 컬럼의 조건은 'BETWEEN' 으로 값이 주어졌음 > 각각의 컬럼에 단일 컬럼 인덱스가 존재 

우선 순위 규칙에 따라 JOB 조건은 규칙 9의 단일 컬럼 인덱스를 만족 > SAL 조건은 규칙 10의 인덱스상의 양쪽 한정 검색을 만족 

> 따라서 우선 순위가 높은 EMP_JOB 인덱스를 이용해서 조건을 만족하는 행에 대해 EMP 테이블을 액세스하는 방식을 선택

 

ㅂ-1) 실행 계획

Execution Plan ----------------- SELECT STATEMENT Optimizer = CHOOSE      TABLE ACCESS (BY INDEX ROWID) OF 'EMP'          INDEX (RANGE SCAN) OF 'EMP_JOB' (NON-UNIQUE)

 

나. 비용기반 옵티마이저

- 규칙기반 옵티마이저의 경우 규칙에 따라 보다 적은 처리 범위로 작업을 할 것이라고 판단하고 실행하지만, 실제로는 그렇지 않을 수 있음.

- 즉, 단순한 몇 개의 규칙만으로 현실의 모든 사항을 정확히 예측할 수 없음.- 비용기반 옵티마이저는 이러한 규칙기반 옵티마이저의 단점을 극복하기 위해 출현- SQL문을 처리하는데 필요한 비용이 가장 적은 실행계획을 선택하는 방식 ( 비용: SQL문을 처리하기 위해 예상되는 소요시간 또는 자원 사용량을 의미)- 비용을 예측하기 위해서 규칙기반 옵티마이저가 사용하지 않는 테이블, 인덱스, 컬럼 등의 다양한 객체 통계정보와 시스템 통계 정보 등을 이용- 통계정보가 없는 경우 비용기반 옵티마이저는 정확한 비용 예측이 불가능해져서 비효율적인 실행계획을 생성 > 정확한 통계정보를 유지하는 것은 비용기반 최적화에서 중요한 요소

▲ 질의 변환기, 대안 계획 생성기, 비용 예측기 등의 모듈로 구성

- 질의 변환기 : 사용자가 작성한 SQL문을 처리하기에 보다 용이한 형태로 변환하는 모듈

- 대안 계획 생성기 : 동일한 결과를 생성하는 다양한 대안 계획을 생성하는 모듈

- 대안 계획 : 연산의 적용 순서 변경, 연산 방법 변경, 조인 순서 변경등을 통해서 생성 > 동일한 결과를 생성하는 가능한 모든 대안 계획을 생성해야 보다 나은 최적화를 수행 > 대안 계획 생성이 너무 많아지면 최적화를 수행하는 시간이 오래 걸림 > 대부분의 상용 옵티마이저들은 대안 계획의 수를 제약하는 다양한 방법 사용 > 제약으로 인해 대안 계획들 중 최적의 대안 계획이 포함되지 않을 수 있음

- 비용 예측기 : 대안 계획 생성기에 의해서 생성된 대안 계획의 비용을 예측하는 모듈 > 정확한 비용을 예측하기 위해서 연산의 중간 집합의 크기 및 결과 집합의 크기, 분포도 등의 예측이 정확해야 함 > 정확한 통계정보를 필요로 함 > 대안 계획을 구성하는 각 연산에 대한 비용 계산식이 정확해야 됨 

- 결론 : 비용기반의 경우 규칙기반과 다르게 인덱스를 사용하는 비용이 전체 테이블 스캔 비용보다 크다고 판단되면 전체 테이블 스캔을 수행하는 방법으로 실행계획 생성 / 통계 정보, dbms 버전, dbms 설정 등의 차이로 동일 sql문이라도 서로 다른 실행계획이 생성될 수 있음.

- 단점 : 다양한 한계들로 인해 실행계획의 예측 및 제어가 어려움.

 

2. 실행계획

 

- SQL에서 요구한 사항을 처리하기 위한 절차와 방법을 의미

- 생성된 실행계획을 보는 방법은 데이터베이스 벤더마다 서로 다름 > 표시되는 내용 및 형태도 약간씩 차이가 있지만 실행계획이 SQL 처리를 위한 절차와 방법을 의미한다는 기본적인 사항은 모두 동일

▲ Oracle 실행 계획 형태 / 실행계획을 구성하는 요소에는 조인 순서, 조인 기법, 액세스 기법, 최적화 정보, 연산 등이 있음.

 

- 조인 순서: 조인작업을 수행할 때 참조하는 테이블의 순서

ex. FROM 절에 A,B 두 개의 테이블이 존재할 때 조인 작업을 위해 먼저 A 테이블을 읽고 B 테이블을 읽는 작업을 수행한다면 조인 순서는 A → B 임 > 위 그림에서 조인 순서는 EMP → DEPT임 > 조인 기법은 두 개의 테이블을 조인할 때 사용할 수 있는 방법으로 NL JOIN, HASH JOIN, SORT MERGE JOIN 등이 있음

- 엑세스 기법 : 하나의 테이블을 액세스 할 때 사용할 수 있는 방법 

     - 인덱스 스캔(index scan) : 인덱스를 이용하여 테이블을 액세스

     - 전체 테이블 스캔(full table scan) : 테이블 전체를 모두 읽으면서 조건을 만족하는 행을 찾는 방법

- 최적화 정보 : 실제로 SQL을 실행하고 얻는 결과가 아니라 통계 정보를 바탕으로 옵티마이저가 계산한 예상치 / 이러한 비용 사항이 실행계획에 표시되지 않는다면 규칙기반 최적화 방식으로 실행계획을 생성한 것임.

     - Cost : 상대적인 비용 정보

     - Card : Cardinality의 약자로서 주어진 조건을 만족한 결과 집합 혹인 조인 조건을 만족한 결과 집합의 건수를 의미

     - Bytes : 결과 집합이 차지하는 메모리 양을 바이트로 표시

- 연산 : 조인 기법(NL Join, Hash Join, Sort Merge Join), 액세스 기법(인덱스 스캔, 전체 테이블 스캔 등), 필터, 정렬, 집계, 뷰 등 다양한 종류가 존재

 

3. SQL 처리 흐름도(Access Flow Diagram)- 내부적인 처리 절차를 시각적으로 표현한 도표- 실행계획을 시각화 한 것

▲ 액세스 처리 흐름도에는 SQL문의 처리를 위해 어떤 테이블을 먼저 읽었는지(조인 순서) > 테이블을 읽기 위해서 인덱스 스캔을 수행했는지 또는 테이블 전체 스캔을 수행했는지(엑세스 기법)와 조인 기법등을 표현

- 조인 순서는 TAB1 → TAB2 / TAB1을 Outer Table 또는 Driving Table이라고 하고, TAB2를 Inner Table 또는 Lookup Table이라고 함.- 테이블 액세스 방법은 TAB1은 테이블 전체 스캔을 의미, TAB2는 IO1_TAB2   이라는 인덱스를 통한 인덱스 스캔을 했음을 표시 한 것.- 조인 방법은 NL Join 을 수행했음을  표시- TAB1에 대한 액세스는 스캔(scan) 방식이고 조인시도 및 

 IO1_TAB2 인덱스를 통한 TAB2 액세스는 랜덤 방식 > 대량의 데이터를 랜던 방식으로 액세스하게 되면 많은 I/O가 발생하여 성능상 좋지 않음.

- 성능적인 관점을 살펴보기 위해서 SQL 처리 흐름도에 일량을 함께 표시할 수 있음. > 건수(액세스 건수, 조인 시도 건수, 테이블 액세스 건수, 성공 건수)라고 표시된 곳에 SQL 처리를 위해 작업한 건수 또는 처리 결과 건수 등의 일량을 함께 표시할 수 있음. >  해당 건수를 통해 어느 부분에서 비효율이 발생하고 있는지에 대한 힌트를 얻을 수 있음.

- 액세스 건수는 SQL 처리를 위해 TAB1을 액세스 한 건수

SELECT ... FROM TAB1 A, TAB2 B WHERE A.KEY = B.KEY AND A.COL1 = :condition1 AND B.COL2 = :condition2

 

- TAB1의 A.COL1 컬럼에 이용 가능한 인덱스가 존재하지 않아 전체 테이블 스캔을 수행했음을 의미

- 액세스 건수는 TAB1 테이블의 총 건수와 동일

- 조인 시도 건수는 TAB1을 액세스한 후 즉, 테이블에서 읽은 해당 건에 대해 A.COL1 = :condition1 조건을 만족한 건만이 TAB2와 조인을 시도

- 조인 시도 건수는 TAB1에 주어진 조건인 A.COL1 = :condition1 을 만족한 건수가 됨.

- 테이블 액세스 건수는 B.KEY 칼럼만으로 구성된 인덱스(B.KEY 칼럼만으로 구성된 인덱스라고 가정함)인 I01_TAB2에서 B.KEY = A.KEY (TAB1은 이미 읽혀졌기 때문에 A.KEY 값은 상수임) 조건을 만족한 건만이 TAB2 테이블을 액세스

- 즉, 조인 시도한 건들 중에서 B.KEY = A.KEY 조건까지 만족한 건과 같음.

- 성공 건수는 SQL 실행을 통해 사용자에게 답으로서 보여지는 결과 건수임.

- TAB2 테이블을 액세스해서 B.COL2 = :condition2 조건까지 만족해야 비로서 사용자에게 보여질 수 있음.

 

 

출처: 

1. http://nclee.tistory.com/entry/%EC%98%B5%ED%8B%B0%EB%A7%88%EC%9D%B4%EC%A0%80%EC%99%80-%EC%8B%A0%EB%82%98%EA%B2%8C-%EB%85%B8%EB%8A%94-%EB%B0%A9%EB%B2%95

2. https://dataonair.or.kr/db.db?cmd=view&boardUid=148208&boardConfigUid=9&categoryUid=216&boardIdx=136&boardStep=1