이 포스트는 “SQL 전문가 가이드”의 “2-3장 SQL 최적화 기본 원리”를 학습한 내용으로 이루어져 있습니다.

옵티마이저와 실행 계획

옵티마이저

옵티마이저(Optimizer)는 사용자가 질의한 SQL문에 대해 최적의 실행 방법을 결정하는 역할을 수행한다. 이러한 최적의 실행 방법을 실행 계획(Execution Plan)이라고 한다. SQL은 사용자의 요구사항만 기술할 뿐 처리 과정을 기술하지 않는다. 다양한 실행 방법 중에 최적의 실행 방법을 결정하는 것이 옵티마이저의 역할이다.

최적의 실행 방법 결정을 옵티마이저는 실제 SQL을 처리하지 않은 상태에서 결정해야 한다. 옵티마이저는 실행 방법을 결정하는 방식에 따라 다음과 같이 나누어진다.

• 규칙 기반 옵티마이저(RBO, Rule Based Optimizer)
• 비용 기반 옵티마이저(CBO, Cost Based Optimizer)

현재 대부분의 관계형 데이터베이스는 비용기반 옵티마이저만을 제공한다. 규칙 기반 옵티마이저를 제공하더라도 신규 기능들에 대해서는 더 이상 지원하지 않고 하위 호환성을 위해서만 제공되고 있다.

규칙 기반 옵티마이저

규칙 기반 옵티마이저는 규칙(우선 순위)를 가지고 실행 계획을 생성한다. 실행 계획을 생성하는 규칙을 이해하면 비교적 쉽게 실행 계획을 예측할 수 있다. 다음은 Oracle의 규칙 기반 옵티마이저의 15가지 규칙이다. 숫자가 낮을수록 높은 우선순위이다.

• 규칙 1. Single row by row id: ROWID를 통해서 테이블에서 하나의 행에 접근하는 방식이다. ROW ID는 행이 포함된 데이터 파일, 블록 등의 정보를 가지고 있기 때문에 다른 정보를 참조하지 않고 바로 접근할 수 있다. 하나의 행에 접근하는 가장 빠른 방법이다.

• 규칙 4. Single row by unique or primary key: 유니크 인덱스를 통해서 하나의 행에 접근하는 방식이다. 이 방식은 인덱스를 먼저 접근하고 인덱스에 존재하는 ROWID를 추출하여 테이블의 행에 접근한다.

• 규칙 8. Composite index: 복합 인덱스에 = 조건으로 검색하는 경우이다. A+B 칼럼으로 복합 인덱스가 생성되어 있고, 조건절에는 WHERE A=1 AND B=1 형태로 검색하는 방식이다. 복합 인덱스 사이의 우선 순위 규칙은 다음과 같다. 인덱스 구성 칼럼의 개수가 더 많고 조건절에 인덱스의 모든 구성 칼럼에 =로 값이 주어질 수록 우선 순위가 더 높다.

• 규칙 9. Single column index: 단일 칼럼 인덱스에 = 조건으로 검색하는 경우이다. A 칼럼에 단일 칼럼 인덱스가 생성되어 있고, A=0 형태로 검색하는 방식이다.

• 규칙 10. Bounded range search on indexed columns: 인덱스가 생성되어 있는 칼럼의 양쪽 범위를 한정하는 형태로 검색하는 방식이다. 이러한 연산자에는 BETWEEN, LIKE 등이 있다. A 칼럼에 인덱스가 생성되어 있고, A BETWEEN ‘10’ AND ‘20’ 또는 A LIKE ‘1%’ 형태로 검색하는 방식이다.

• 규칙 11. Unbounded range search on indexed columns: 인덱스가 생성되어 있는 칼럼에 한쪽 범위만 한정하는 형태로 검색하는 방식이다. 이러한 연산자에는 >, >=, <, <= 등이 있다.

• 규칙 15. Full table scan: 전체 테이블에 접근하면서 조건절에 주어진 조건을 만족하는 행만을 추출한다.

규칙 기반 옵티마이저의 조인 순서 결정 방법

• 조인 칼럼 인덱스의 존재 유무가 중요한 판단 기준

규칙 기반 옵티마이저의 조인 기법

• 양쪽 조인 칼럼에 모두 인덱스가 없는 경우: Sort Merge Join
• 둘 중 하나라도 조인 칼럼에 인덱스가 존재하는 경우: NL Join

비용 기반 옵티마이저

단순히 몇 개의 규칙만으로 현실의 모든 사항을 정확히 예측할 수 없다. 비용 기반 옵티마이저는 SQL 문을 처리하는데 필요한 비용이 가장 적은 실행 계획을 선택하는 방식이다. 비용 기반 옵티마이저는 비용을 예측하기 위해 객체 통계 정보와 시스템 통계 정보등을 이용한다. 정확한 통계 정보를 유지하는 것은 비용 기반 최적화에서 중요한 요소이다.

비용 기반 옵티마이저는 다음과 같은 요소들로 이루어져 있다.

• 질의 변환기: SQL문을 처리하기에 보다 용이한 형태로 변환하는 모듈
• 대안 계획 생성기: 동일한 결과를 생성하는 다양한 대안 계획을 생성하는 모듈
• 비용 예측기: 대안 계획의 비용을 예측하는 모듈

비용 기반 옵티마이저는 통계 정보, DBMS 버전, DBMS 설정 정보등의 차이로 동일한 SQL 문에서도 서로 다른 실행 계획이 생성될 수 있다. 이렇기 때문에 실행계획의 예측 및 제어가 어렵다는 단점이 있다.

실행 계획(Execution Plan)

실행 계획이란 SQL에서 요구한 사항을 처리하기 위한 절차와 방법을 의미한다. 생성된 실행 계획을 보는 방법은 데이터베이스 벤더마다 서로 다르다. 실행 계획을 구성하는 요소에는 조인 순서(Join Order), 조인 기법(Join Method), 액세스 기법(Access Method), 최적화 정보(Optimization information), 연산(Operation) 등이 있다.

Rows      Execution Plan
--------  ----------------------------------------------------
      12  SORT AGGREGATE
       2   SORT GROUP BY
   76563    NESTED LOOPS
   76575     NESTED LOOPS
      19      TABLE ACCESS FULL CN_PAYRUNS_ALL
   76570      TABLE ACCESS BY INDEX ROWID CN_POSTING_DETAILS_ALL
   76570       INDEX RANGE SCAN (object id 178321)
   76563     TABLE ACCESS BY INDEX ROWID CN_PAYMENT_WORKSHEETS_ALL
11432983      INDEX RANGE SCAN (object id 186024)

http://docs.oracle.com/cd/B19306_01/server.102/b14211/ex_plan.htm#i25909

인덱스 기본

인덱스 특징과 종류

인덱스는 색인과 비슷한 개념으로 원하는 데이터를 쉽게 찾을 수 있도록 돕는다. 인덱스의 기본적인 목적은 검색 성능의 최적화이다. 검색 조건을 만족하는 데이터를 인덱스를 통해 효과적으로 찾을 수 있도록 돕는다. 반대로 CUD 작업은 테이블과 인덱스를 함께 변경하기 때문에 오히려 느려질 수 있다.

트리기반 인덱스
DBMS에서 가장 일반적인 인덱스는 B-트리 인덱스이다. B-트리 인덱스는 브랜치 블록과 리프 블록으로 구성된다. 리프 블록은 트리의 가장 아래 단계에 위치하며 칼럼의 정보와 데이터의 위치를 가지고 있는 RID로 구성되어 있다. 리프 블록은 양방향 링크를 가지고 있다. 이것을 통해서 오름 차순과 내림 차순 검색을 할 수 있다. B-트리 인덱스는 일치 검색, 범위 검색에 적합한 구조이다.

인덱스를 생성할 때 동일 칼럼으로 구성된 인덱스를 중복해서 생성할 수 없다. 하지만 칼럼의 순서가 다르면 서로 다른 인덱스를 생성할 수 있다. 인덱스의 칼럼 순서는 질의의 성능에 중요한 영향을 미치는 요소이다.

클러스터형 인덱스
SQL Server의 인덱스 종류는 저장 구조에 따라 클러스터형 인덱스와 비클러스터형 인덱스로 나뉜다. 클러스터형 인덱스는 다음과 같은 특징을 가진다.

• 인덱스의 리프 페이지가 곧 데이터 페이지이다. 그러므로 테이블 탐색에 필요한 RID가 리프 페이지에 없다. 클러스터형 인덱스의 리프 페이지를 탐색하면 해당 테이블의 모든 칼럼 값을 곧바로 얻을 수 있다.
• 리프 페지이의 모든 로우(=데이터)는 인덱스 키 카 칼럼 순으로 물리적으로 정렬되어 저장된다. 테이블 로우는 물리적으로 한 가지 순서로만 정렬될 수 있다. 그러므로 클러스터형 인덱스는 테이블 당 한개만 생성할 수 있다.

전체 테이블 스캔과 인덱스 스캔

전체 테이블 스캔
전체 테이블 스캔 방식은 테이블에 존재하는 모든 데이터를 읽어가며 조건에 맞으면 결과로서 추출하고 맞지 않으면 버리는 방식으로 검색한다. 이렇게 읽은 블록들은 재사용성이 떨어지므로 메모리에서 곧 제거될 수 있도록 관리된다. 옵티마이저가 Full Table Scan을 선택하는 이유는 다음과 같다.

• SQL문에 조건이 존재하지 않는 경우
• SQL문의 주어진 조건에 사용 가능한 인덱스가 존재하지 않는 경우
• 옵티마이저의 취사 선택 (조건을 만족하는 데이터가 많아 대부분의 블록을 액세스 해야 한다고 판단될 때)
• 그 박의 경우 (병렬 처리 방식, 힌트 사용)

인덱스 스캔(트리기반 인덱스)
인덱스 스캔은 인덱스를 구성하는 칼럼의 값을 기반으로 데이터를 추출하는 접근 기법이다. 인덱스의 리프 블록은 인덱스를 구성하는 칼럼과 레코드 식별자로 구성되어 있다. 검색을 위해 인덱스의 리프 블록을 읽으면 인덱스 구성 칼럼의 값과 테이블의 레코드 식별자를 알 수 있다.

인덱스 스캔 중에서 자주 사용되는 방식은 인덱스 유일 스캔, 인덱스 범위 스캔, 인덱스 역순 범위 스캔이다.

• 인덱스 유일 스캔(Index Unique Scan): 유일 인덱스(Unique Index)를 사용하여 단 하나의 데이터를 추출하는 방식이다. 유일 인덱스 구성 칼럼에 =로 값이 주어지면 경우에 이루어진다. (결과는 0~1건)

• 인덱스 범위 스캔(Index Range Scan): 한 건 이상의 데이터를 추출하는 방식이다. 유일 인덱스의 구성 칼럼 모두에 대해 =로 값이 주어지지 않은 경우와 비유일 인덱스를 이용하는 모든 접근 방식은 인덱서 범위 스캔 방식이다.

• 인덱스 역순 범위 스캔(Index Range Scan Descending): 인덱스 리프 블록의 양방향 링크를 이용하여 내림 차순으로 데이터를 읽는 방식이다. 최대값을 쉽게 찾ㅇ르 수 있다.

이 외에도 인덱스 전체 스캔, 인덱스 고속 전체 스캔, 인덱스 스킵 스캔 등이 있다.

인덱스 스캔은 인덱스에 존재하는 RID를 이용해 한 번의 I/O 요청에 한 블록의 데이터를 읽는다. 그러나 전체 테이블 스캔은 데이터를 읽을 때 한 번의 I/O 요청으로 여러 블록을 읽는다. 어차피 모든 데이터를 읽을 것이라면 한 번 읽기 작업을 할 때 여러 블록을 함게 읽는 것이 효율적이다.

조인 수행 원리

조인이란 두 개 이상의 테이블을 하나의 집합으로 만드는 연산이다. 조인 연산은 두 테이블 사이에서 수행된다. FROM 절에 3 개의 테이블이 존재하더라도 2개의 테이블에 대해 먼저 조인을 수행한 후 나머지 테이블을 조인한다.

NL Join

NL Join은 프로그래밍에서 사용되는 중첩된 반복문과 유사한 방식으로 조인을 수행한다.

FOR 선행 테이블 읽음 ->  외부 테이블(Outer Table)
	For 후행 테이블 읽음 -> 내부 테이블(Inner Table)
		(선행 테이블과 후행 테이블 조인)

1. 선행 테이블에서 주어진 조건을 만족하는 행을 찾음
2. 선행 테이블의 조인 키 값을 가지고 후행 테이블에서 조인 수행
3. 선행 테이블의 조건을 만족하는 모든 행에 대해 1번 작업 반복 수행

결과 행의 수가 적은 테이블을 선행 테이블로 선택하는 것이 더 효율적이다. 조인이 성공하면 바로 조인 결과를 사용자에게 보여줄 수 있다. 결과를 가능한 빨리 화면에 보여줘야 하는 온라인 프로그램에 적당한 조인 기법이다.

Sort Merge Join

Sort Merge Join은 조인 칼럼을 기준으로 데이터를 정렬하여 조인을 수행 한다. NL Join은 주로 랜덤 액세스 방식으로 데이터를 읽는다. 반면 Sort Merge Join은 스캔 방식으로 데이터를 읽는다. Sort Merge Join은 넓은 범위의 데이터를 처리할 때 이용되던 조인 기법이다. 일반적으로 대량의 조인 작업에서 정렬 작업을 필요로 하는 Sort Merge Join 보다는 CPU 작업 위주로 처리하는 Hash Join이 성능상 유리하다. 하지만 Sort Merge Join은 동등 조인 뿐만 아니라 비동등 조인에 대해서도 조인 작업이 가능하다.

1. 선행 테이블에서 주어진 조건을 만족하는 행을 찾음
2. 선행 테이블의 조인 키를 기준으로 정렬 작업을 수행
3. 1 - 2번 작업을 선행 테이블의 조건을 만족하는 모든 행에 대해 반복 수행
4. 후행 테이블에서 주어진 조건을 만족하는 행을 찾음
5. 후행 테이블의 조인 키를 기준으로 정렬 작업을 수행
6. 4 - 5번 작업을 후행 테이블의 조건을 만족하는 모든 행에 대해 반복 수행
7. 정렬된 결과를 이용하여 조인을 수행하며 조인에 성공하면 추출버퍼에 넣음

Sort Merge Join은 조인 칼럼의 인덱스를 사용하지 않기 때문에 칼럼의 인덱스가 없을 때에도 사용할 수 있는 조인 기법이다. 미리 정렬된 데이터를 조인하면 정렬 작업이 발생하지 않을 수 있다.

Hash Join

Hash Join은 해싱 기법을 이용하여 조인을 수행한다. 조인을 수행할 테이블의 조인 칼럼을 기준으로 해쉬 함수를 수행하여 서로 동일한 해쉬 값을 갖는 것들 사이에서 실제 값이 같은지를 비교하면서 조인을 수행한다. NL Join의 랜덤 액세스 문제점과 Sort Merge Join의 문제점인 정렬 작업의 부담을 해결하기 위한 대안으로 등장하였다.

1. 선행 테이블에서 주어진 조건을 만족하는 행을 찾음
2. 선행 테이블의 조인 키를 기준으로 해쉬 함수를 적용하여 해쉬 테이블을 생성
   • 조인 칼럼과 SELECT 절에서 필요로 하는 칼럼도 함께 저장됨.
3. 1 - 2번 작업을 선행 테이블의 조건을 만족하는 모든 행에 대해 반복 수행
4. 후행 테이블에서 주어진 조건을 만족하는 행을 찾음
5. 후행 테이블의 조인 키를 기준으로 해쉬 함수를 적용하여 해당 버킷을 찾음
   • 조인 키를 이용해서 실제 조인될 데이터를 찾음
6. 조인에 성공하면 추출 버퍼에 넣음
7. 4 - 6번 작업을 후행 테이블의 조건을 만족하는 모든 행에 대해서 반복 수행

Hash Join은 조인 칼럼의 인덱스를 사용하지 않기 때문에 칼럼의 인덱스가 없을 때에도 사용할 수 있는 조인 기법이다. 해쉬 함수를 이용하여 조인을 수행하기 때문에 =로 수행하는 동등 조인에서만 사용할 수 있다. 조인을 수행하기 위해 해쉬 테이블을 메모리에 생성해야 한다. 메모리보다 커지면 스왑 메모리를 사용하기 때문에 행의 수가 적은 테이블을 선행 테이블로 하는 것이 좋다.

Hash Join에서는 선행 테이블을 이용하여 먼저 해쉬 테이블을 생성한다고 해서 선행 테이블을 Build Input이라고도 한다. 후행 테이블은 만들어진 해쉬 테이블에 대해 해쉬 값의 존재 여부를 검사한다고 해서 Prove Input이라고도 한다.

출처: "SQL 전문가 가이드, 2013 Edition", 서강수, 한국데이터베이스진흥원, 2013