[SQLD] 2과목 - 3장 SQL 최적화 기본 원리 요약

한국데이터산업진흥원 게시자료에 기반한 요약 정리

2과목 SQL 기본 및 활용

3장 SQL 최적화 기본 원리

 

 

 

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

 

옵티마이저

사용자가 질의한 SQL문에 대한 최적의 실행방법을 결정하여 실행 계획 도출

SQL문에 대한 파싱 후 실행됨
 

 

※ SQL문 실행 순서 ※ 
1. 파싱(Parsing) : SQL 문법 검사 및 구문 분석 작업
2. 실행(Execution) : 옵티마이저의 실행 계획에 따라
3. 인출(Fetch) : 데이터를 읽어 전송
 

 

옵티마이저 엔진

- 질의 변환기(Query Transformer): 작성된 SQL문을 처리하기 용이한 형태로 변환하는 모듈
- 비용 예측기(Estimator): 생성된 계획의 비용을 예측하는 모듈
- 대안계획 생성기(Plan Generator): 동일한 결과를 생성하는 다양한 대안 계획을 생성하는 모듈,
1) 연산 적용 순서 2) 연산 방법 3) 조인 순서의 변경을 통해 대안 계획 생성
 

옵티마이저 종류

- 규칙기반 옵티마이저

우선순위 규칙에 따라 실행계획 생성

우선 순위가 높은 규칙이 적은 일량으로 해당 작업을 수행한 다고 판단한다.

인덱스가 있으면 반드시 인덱스 사용

- 비용기반 옵티마이저

현재 대부분의 DB에서 사용

SQL문을 처리하는데 필요한 비용이 가장 적은 실행계획을 선택하는 방식

비용이란? SQL문을 처리하기 위해 예상되는 소요시간 또는 자원 사용량을 의미

테이블,인덱스,칼럼 등 다양한 객체 통계정보와 시스템 통계정보 등을 이용
데이터 딕셔너리(Data Dictionary)의 통계정보나 DBMS의 차이로 같은 쿼리도 다른 실행계획이 생성될 수 있음
실행계획의 예측 및 제어가 어려움

 
 

 

SQL 처리 흐름도: SQL문의 처리절차를 시각적으로 표현한 도표

 

 실행계획

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

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

1) 객체 2) 조인 방법 및 순서 3) 액세스 패턴 등의 정보 출력
 
DESC PLAN_TABLE; : 실행 계획 확인
 
해독 순서 : ←로 찾다가 2줄 이상의 동일 레벨을 만나면 ↓로 해독
 

 

---

 

2절 인덱스 기본

 
인덱스

검색 조건에 부합하는 데이터를 효과적으로 검색할 수 있도록 돕는 기능

원하는 데이터를 쉽게 찾을 수 있도록 돕는 책의 찾아보기와 유사한 개념

인덱스키로 정렬되어 있어 조회 속도가 빠름

검색 성능의 최적화를 목적으로 두고 있지만 느려질 수 있다는 단점이 존재 => DML 작업 효율은 저하함

 

 

트리기반 인덱스

DBMS에서 사용하는 가장 일반적인 인덱스,
1) 루트 블록(Root Block)

2) 브랜치 블록(Branch Block)

3) 리프 블록(Leaf Block)으로 구성됨
 
- 포인터(Pointer): 루트 블록과 브랜치 블록의 키 값, 하위 블록 키 값의 범위 정보
- 리프 블록은 1) 인덱스키 2) ROWID로 구성됨, Doubly Linked List 형태라서 양방향 탐색 가능
 
※ ROWID ※ 
Oracle에서 데이터를 구분할 수 있는 유일한 값,
데이터를 입력하면 자동으로 생성됨,
데이터가 어떤 데이터 파일의 어느 블록에 속해 있는지 알려줌
 
• 오브젝트 번호: 해당 데이터가 속하는 오브젝트 번호, 오브젝트 별로 유일한 값을 가짐
• 상대 파일 번호: 테이블스페이스 내 데이터 파일의 순번
• 블록 번호: 데이터 파일 내 데이터가 속해 있는 블록의 순번
• 데이터 번호: 데이터 블록에 데이터가 저장되어 있는 순번

 

B-TREE 인덱스에서 원하는 값을 찾는 과정
1. 브랜치 블록의 가장 왼쪽 값이 찾고자 하는 값보다 작거나 같으면 왼쪽 포인터로 이동
2. 찾고자 하는 값이 브랜치 블록의 값 사이에 존재하면 가운데 포인터로 이동
3. 오른쪽에 있는 값보다 크면 오른쪽 포인터로 이동

 

 

클러스터형 인덱스 (SQL Server)

인덱스의 리프 페이지가 데이터를 포함함,

리프 페이지의 모든 로우가 인덱스키 칼럼 순서대로 물리적으로 정렬되어 있음
 
CREATE INDEX 인덱스명 테이블명 ON 테이블명 (칼럼명, …) : 인덱스 생성
※ 인덱스키가 변환되면 사용 불가                 
ex) NVL(인덱스키,값), TO_타입(인덱스키), 인덱스키||값
 

 

인덱스 스캔 

인덱스를 구성하는 칼럼의 값을 기반으로 데이터를 추출하는 액세스 기법

 

 

인덱스 스캔 효율화

랜덤 액세스 최소화

인덱스 스캔 후 추가 정보를 가져오기 위한 랜덤 액세스는 DBMS 성능 부하를 유발함
※ 인덱스 칼럼의 순서는 랜덤 액세스와 무관함
 

스캔 방법

✔      전체 테이블 스캔(Full Table Scan):

테이블의 모든 데이터를 읽으며 데이터 추출,

테이블에 존재하는 모든 데이터를 읽어 가면서 조건에 맞으면 결과로서 추출하고 조건에 맞지 않으면 버리는 방식으로 검색
읽은 블록의 재사용성을 낮다고 판단하여 메모리 버퍼에서 제거함,

 

전체 테이블 스캔을 하는 경우
1) SQL문에 조건이 없거나
2) SQL문 조건에서 사용가능한 인덱스가 없거나
3) 전체 테이블 스캔을 하도록 강제로 힌트를 지정하거나
4) 옵티마이저가 유리하다고 판단하는 경우 수행, 많은 데이터를 조회할 때 유리함

 
✔      인덱스 스캔(Index Scan):

유일 인덱스를 사용하여 단 하나의 데이터를 추출하는 방식

(중복X, 구성 칼럼에 대해 모두 ‘=’ 로 값이 주어진 경우에만 가능)
인덱스를 구성하는 칼럼의 값을 기반으로 데이터 추출,
인덱스를 읽어 ROWID를 찾고 해당 데이터를 찾기 위해 테이블을 읽음,
일반적으로 인덱스 칼럼 순서로 정렬되어 출력됨,
적은 데이터를 조회할 때 유리함,

1) 랜덤 액세스에 의한 부하가 발생할 수 있고 2) 중복 스캔 비효율이 발생함
 

 

✔      인덱스 범위 스캔(Index Range Scan)

특정 범위에 인덱스 스캔 적용

인덱스를 이용하여 한 건 이상의 데이터를 추출하는 방식

- 인덱스 역순 범위 스캔: 인덱스의 리프 블록의 양방향 링크를 이용하여 내림차순으로 데이터를 읽는다

리프 블록의 Doubly Linked List 저장 방식을 활용하여 인덱스를 역순으로 스캔, 결과 집합이 내림차순으로 정렬됨
 

 

✔      인덱스 유일 스캔(Index Unique Scan):
인덱스키가 중복되지 않을 때 단 한 건의 데이터 추출, 등호 조건으로 조회함, 검색 속도가 가장 빠름
 

 

✔      인덱스 전체 스캔(Index Full Scan): 리프 블록을 모두 읽으며 데이터 추출
- 인덱스 고속 전체 스캔: 물리적으로 저장된 순서대로 인덱스 리프 블록 스캔
- 인덱스 스킵 스캔: 인덱스 선두 칼럼이 조건절에 없어도 활용함,

상위 블록에서 읽은 칼럼 값 정보를 이용해 조건에 맞는 데이터를 포함할 가능성이 있는 리프 블록만 접근
 

 

IOT(Index-Organized Table)

인덱스키가 붙은 칼럼으로 구성된 테이블,

인덱스가 원래 테이블을 참조하지 않음,

클러스터형 인덱스와 유사함

 

 

인덱스에 대해서 연산을 하면 인덱스가 변형이 되므로 인덱스를 사용할수가 없다
 

 

---

 

3절 조인 수행 원리

 
1. 조인 순서

항상 두 테이블을 조인함
✔      선행 테이블(First Table, Outer Table, Driving Table, Build Input)
✔      후행 테이블(Second Table, Inner Table, Driven Table, Probe Input)

선행 테이블로부터 입력값을 받아 처리함, 후행 테이블에 걸리는 조인 조건이 성능에 큰 영향을 미침
 

2. 조인 방식

NL 조인 > 소트 머지 조인 > 해시 조인 순서로 발전됨

 

✔      NL 조인(Nested Loop Join)

프로그래밍에서 사용하는 중첩된 반복문과 유사한 방식으로 

조인을 수행, 랜덤 액세스 방식으로 데이터를 읽는다.

선행 테이블의 데이터 하나씩 순차적으로 조인(중첩 반복문과 유사),

선행 테이블 처리 범위가 성능을 결정함 (~ 해시 조인, ↔ 소트 머지 조인은 순서에 무관함),

랜덤 액세스 위주이므로 대용량 데이터 처리 시 불리

 

유니크 인덱스를 이용하여 소량 테이블 조인할 때 유리함
 
절차
1.선행 테이블에서 조건을 만족하는 행을 찾음
2.후행 테이블에 선행 테이블의 조인키가 존재하는지 확인함
3.후행 테이블 인덱스에 선행 테이블의 조인키가 존재하는지 확인함
4 .인덱스에서 추출한 ROWID로 후행 테이블을 액세스함
 
조인 결과를 하나씩 바로 출력하여 OLTP 환경에 적합함

 
✔      소트 머지 조인(Sort Merge Join)

조인 칼럼을 기준으로 데이터를 정렬하여 조인을 수행, 스캔 방식으로 데이터 읽음.
두 테이블을 개별적으로 스캔한 후 조인 (↔ NL 조인은 선행 테이블을 랜덤 액세스 방식으로 조회하며 조인),

대용량 데이터 처리 시 디스크에서 정렬이 진행되므로 성능상 불리,

인덱스 유무가 성능에 큰 영향을 주지 않음 (↔ NL 조인은 인덱스 구성에 크게 영향을 받음)
 

 

✔      해시 조인(Hash Join)

CPU 작업 위주로 처리, 해슁 기법 이용, 

NL Join의 랜덤 액세스 문제와 SMJ의 정렬 작업부담을 해결하기 위한 대안으로 등장
조인 칼럼을 기준으로 동일한 해시 값을 갖는 데이터의 실제 값을 비교하며 조인,

두 테이블의 데이터 차이가 클 때 유리,

1) NL 조인의 랜덤 액세스와 2) 소트 머지 조인의 정렬 작업 부담 해결,

등가 조인에서만 사용할 수 있음,

해시 메모리에서 해시 테이블을 생성하므로 선행 테이블이 작을 때 유리 테이블이 커서 소트 부하가 심할 때 유리함
 
OLAP 환경에 적합함