[SQLD] 2과목 - 4장. SQL 최적화 기본 원리

(최적화 부분은 출제 지양)

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

1. 옵티마이저

: SQL문에 대한 최적의 실행방법을 결정하여 실행 계획 도출, SQL문에 대한 파싱 후 실행됨, 내비게이션

 

<SQL문 실행 순서>

1. SQL문 작성
2. 파싱(Parsing) : SQL 문법 검사 및 구문 분석 작업
3. 옵티마이저(비용기반/규칙기반)
4. 실행(Execution) : 옵티마이저의 실행 계획에 따라
5. 인출(Fetch) : 데이터를 읽어 전송

 

• 옵티마이저 엔진
  • 질의 변환기(Query Transformer) : 작성된 SQL문을 처리하기 용이한 형태로 변환하는 모듈
  • 비용 예측기(Estimator) : 생성된 계획의 비용을 예측하는 모듈. 총 비용은 최적의 실행 계획을 수립하기 위함
  • 대안계획 생성기(Plan Generator) : 동일한 결과를 생성하는 다양한 대안 계획을 생성하는 모듈
    1) 연산 적용 순서
    2) 연산 방법
    3) 조인 순서의 변경을 통해 대안 계획 생성

2. 종류

• 규칙기반 옵티마이저
  : 15개 우선순위 규칙에 따라 실행계획 생성, 인덱스가 있으면 반드시 인덱스 사용

우선순위	설명
1	ROWID를 사용한 단일 행인 경우
2	클러스터 조인에 의한 단일 행인 경우
3	유일하거나 기본키(Primary Key)를 가진 해시 클러스터 키에 의한 단일 행인 경우
4	유일하거나 기본키(Primary Key)에 의한 단일 행인 경우
5	클러스터 조인인 경우
6	해시 클러스터 조인인 경우
7	인덱스 클러스터 키인 경우
8	복합 칼럼 인덱스인 경우
9	단일 칼럼 인덱스인 경우
10	인덱스가 구성된 칼럼에서 제한된 범위를 검색하는 경우
11	인덱스가 구성된 칼럼에서 무제한 범위를 검색하는 경우
12	정렬-병합(Sort-Merge) 조인인 경우
13	인덱스가 구성된 칼럼에서 MAX 혹은 MIN을 구하는 경우
14	인덱스가 구성된 칼럼에서 ORDER BY를 실행하는 경우
15	전체 테이블을 스캔(FULL TABLE SCAN)하는 경우

 

• 비용기반 옵티마이저, CBO
  • 처리비용이 가장 적은 실행계획 선택
  • 데이터 딕셔너리의 통계정보나 DBMS의 차이로 같은 쿼리도 다른 실행계획이 생성될 수 있음
  • 단계별 예상비용 및 건수 표시
  • 실행계획의 예측 및 제어가 어려움
  • 인덱스가 존재하더라도 전체 테이블 스캔이 유리하다고 판단할 수 있음.

 

3. SQL 처리 흐름도

: SQL 처리절차, 실행계획을 시각화한 도표

인덱스 스캔, 테이블 전체 스캔 등과 같은 액세스 기법이 표현된다.

SQL의 내부적인 처리 절차를 시각적으로 표현해준다. (실행시간을 알순 없다.)

성능적인 측면도 표현할 수 있음.

 

 

4. 실행계획

1. 객체
2. 조인 방법 및 순서
3. 액세스 기법, 패턴
4. 질의처리 예상 비용(cost) 등의 정보 출력

• 동일 SQL문에 대해 실행계획이 다르더라도 결과가 달라지지는 않는다.
• DESC PLAN_TABLE; 실행 계획 확인
• 해독 순서 : 같은 레벨의 경우 (위-아래), 상하 레벨인 경우(하위-상위) 순으로

---

2절. 인덱스 기본

2-1. 인덱스

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

• 인덱스키로 정렬(내림차순)되어 있어 조회 속도가 빠름, 자주 변하는 속성은 인덱스로 설정X
• 한개의 인덱스는 여러 칼럼으로 구성
• 한 개의 테이블에 여러 인덱스 생성가능
• 기본 인덱스에 널값은 나타날 수 없음.
• 보조인덱스는 UNIQUE가 아니라면 중복 데이터 입력가능
• 인덱스 칼럼의 순서는 데이터 조회 시 성능에는 중요한 역할
• DML 작업 효율은 저하함, INSERT,DELETE 작업과는 다르게 UPDATE 작업에는 부하가 없을 수도 있다.

 

2-2. 트리기반 인덱스(B-TREE)

: 일반적으로 OLTP 시스템 환경, DBMS에서 가장 많이 사용된다. 일치 및 범위 검색에 적절.

 

• 구성 : 브랜치 블록(Branch Block), 리프 블록(Leaf Block)
  • 브랜치 블록은 분기를 목적
    가장 상위에 있는 블록은 루트 블록이라고 한다. (리프 블록은 가장 아래 단계)
  • 리프 블록은 1) 인덱스를 구성하는 컬럼의 데이터와 레코드 식별자(RID)로 구성 
    2) Doubly Linked List 형태라서 양방향 탐색 가능 (인덱스역순범위 스캔) 
    3) 리프블록은 인덱스를 구성하는 컬럼의 값으로 정렬된다.
• 포인터(Pointer) : 루트 블록과 브랜치 블록의 키값, 하위 블록 키 값의 범위 정보

 

 

2-3. CLUSTERED 인덱스

: 인덱스의 리프 페이지가 곧 데이터 페이지이며, 리프 페이지의 모든 데이터는 인덱스 키 컬럼 순으로 물리적으로 정렬되어 저장된다.

 

2-4. BITMAP 인덱스

: 시스템에서 사용될 질의를 시스템 구현 시에 모두 알 수 없는 경우인 DM 및 AD-HOC 질의 환경을 위해서 설계되었으며, 하나의 인덱스 키 인트리가 많은 행에 대한 포인터를 저장하고 있는 구조이다.

 

※ ROWID : Oracle에서 데이터를 구분할 수 있는 유일한 값, 데이터를 입력하면 자동으로 생성됨 데이터가 어떤 데이터 파일의 어느 블록에 속해 있는지 알려줌.

• 오브젝트 번호 : 해당 데이터가 속하는 오브젝트 번호, 오브젝트 별로 유일한 값을 가짐
• 상대 파일 번호 : 테이블스페이스 내 데이터 파일의 순번
• 블록 번호 : 데이터 파일 내 데이터가 속해 있는 블록의 순번
• 데이터 번호 : 데이터 블록에 데이터가 저장되어 있는 순번

인덱스 생성 :

CREATE INDEX 인덱스명 테이블명 ON 테이블명 (칼럼명, …) 

 

※ 인덱스키가 변환되면 사용 불가

ex) NVL(인덱스키,값), TO_타입(인덱스키), 인덱스키||값

 

2-5. 인덱스 스캔 효율화

: 랜덤 액세스 최소화 (일반적으로 ROWID를 기반으로 스캔하는 것이 가장 높은 우선순위 가짐. 인덱스 스캔 후 추가정보를 가져오기 위한 랜덤액세스는 DBMS 성능 부하를 유발함. )

※ 인덱스 칼럼의 순서는 랜덤 액세스와 무관함/ 인덱스 칼럼의 순서는 데이터 조회 시 성능에는 중요한 역할이다.

 

2-6. 스캔 방법

1. 전체 테이블 스캔(Full Table Scan)

• 테이블의 모든 데이터를 읽으며 데이터 추출. 인덱스는 거의 불필요하다.
• 읽은 블록의 재사용성을 낮다고 판단하여 메모리 버퍼에서 제거함. 많은 데이터를 조회할 때 유리함.
  1) SQL문에 조건이 없거나
  2) SQL문 조건 관련 인덱스가 없거나
  3) 전체 테이블 스캔을 하도록 강제로 힌트를 지정하거나
  4) 옵티마이저가 유리하다고 판단하는 경우 수행

2. 인덱스 스캔(Index Scan)

• 인덱스를 구성하는 칼럼의 값을 기반으로 데이터 추출.
• 인덱스를 읽어 ROWID를 찾고 해당 데이터를 찾기 위해 테이블을 읽음.
• 대량의 데이터를 삽입할때는 모든 인덱스를 삭제하고, 데이터 삽입후에 인덱스를 다시 생성하는 것이 좋다.
• 일반적으로 인덱스 칼럼 순서로 정렬되어 출력됨, 적은 데이터를 조회할 때 유리함.
  1) 랜덤 액세스에 의한 부하가 발생할 수 있고
  2) 중복 스캔 비효율이 발생함

인덱스 범위 스캔(Index Range Scan)	특정 범위에 인덱스 스캔 적용
	인덱스 역순 범위 스캔 : 리프 블록의 Doubly Linked List 저장 방식을 활용, 결과 집합이 내림차순으로 정렬됨. 범위에 따라 복수뿐만 아니라 단수의 결과 혹은 0건의 결과 출력도 가능
인덱스 유일 스캔(Index Unique Scan)	인덱스키가 중복되지 않을 때 단 1건의 데이터 추출.  등호 조건으로 조회함 검색 속도가 가장 빠름
인덱스 전체 스캔(Index Full Scan)	리프 블록을 모두 읽으며 데이터 추출
	인덱스 고속 전체 스캔 : 물리적으로 저장된 순서대로 인덱스 리프 블록 스캔
	인덱스 스킵 스캔 : 인덱스 선두 칼럼이 조건절에 없어도 활용함
	상위 블록에서 읽은 칼럼값 정보를 이용해 조건에 맞는 데이터를 포함할 가능성이 있는 리프 블록만 접근

• IOT(Index-Organized Table) : 인덱스키가 붙은 칼럼으로 구성된 테이블, 인덱스가 원래 테이블을 참조하지 않음, 클러스터형 인덱스와 유사함

---

3절. 조인 수행 원리 ★

조인 순서 : 항상 두 테이블을 조인함

• 선행 테이블(First Table, Outer Table, Driving Table, Build Input)
• 후행 테이블(Second Table, Inner Table, Driven Table, Probe Input) : 선행 테이블로부터 입력값을 받아 처리함, 후행 테이블에 걸리는 조인 조건이 성능에 큰 영향을 미침

조인 방식 : NL 조인 > 소트 머지 조인 > 해시 조인 순서로 발전됨DW 등의 데이터 집계 업무에서 많이 사용되는 기법은 소프트 머지, 해쉬 조인이다.

 

NL 조인(Nested Loop Join)	조인 칼럼에 적당한 인덱스가 있어서 자연조인(Natural Join)이 효율적일 때 유용하다.
	선택도가 낮은(결과 행의 수가 적은) 테이블이 선행 테이블로 선택되는 것이 일반적으로 유리.
	Driving Table의 조인 데이터 양이 큰 영향을 주는 조인 방식이다.
	선행 테이블의 데이터부터 하나씩 순차적으로 조인 (선행테이블→내부테이블 연결)
	선행 테이블 처리범위가 성능을 결정함.
	랜덤 액세스 위주이므로 대용량 데이터 처리시 불리.
	INDEX 필수 (유니크 인덱스로 소량 테이블을 온라인 조인할때 유리함)
	조인결과를 하나씩 바로 출력하여 OLTP 환경에 적합함
	1) 선행 테이블에서 조건을 만족하는 행을 찾음 2) 후행 테이블에 선행 테이블의 조인키가 존재하는지 확인함 3) 후행 테이블 인덱스에 선행 테이블의 조인키가 존재하는지 확인함 4) 인덱스에서 추출한 ROWID로 후행 테이블을 액세스함
소트 머지 조인 (Sort Merge Join)	두 테이블을 개별적으로 정렬하여 스캔한 후 조인, 데이터 많을수록 느려짐
	대용량 데이터 처리 시 임시디스크에서 정렬이 진행되므로 성능상 불리
	인덱스 유무가 성능에 큰 영향을 주지 않음  (↔ NL 조인은 인덱스 구성에 크게 영향을 받음)
	EQUI JOIN, NON-EQUI JOIN ★
해시 조인(Hash Join)	조인 컬럼에 적당한 인덱스가 없어서 자연조인(Natural Join)이 비효율적일 때 사용
	두 테이블의 데이터 차이가 클때 유리. 대용량 처리에 빠름. 시스템 자원 최대한 활용 가능.
	조인칼럼을 기준으로 동일한 해시값을 갖는 데이터의 실제값을 비교하며 조인
	해시메모리에서 해시테이블을 생성하므로 결과 행의 수가 작은 테이블을 선행테이블로 사용하는것이 유리.
	테이블이 커서 소트부하가 심할때 유리
	동시스캔. 작은 테이블을 hash메모리에 로딩하고 두 테이블의 조인키로 해시테이블 생성.
	OLAP 환경에 적합함
	EQUI JOIN 만 가능 ★

 

---

4절. 데이터 무결성 강화 방법

1. 데이터 무결성

• 개체 무결성(entity integrity) : 기본키로 선택된 열은 고유해야하며 null값을 가질 수 없다.
• 참조 무결성(reference integrity) : 기본키와 외래키의 관계이다.
  외래키가 있는 테이블의 경우에는키본키와 외래키간의 관계가 항상 유지됨을 보장한다.
  참조하는 외래키가 존재하면 행 삭제 불가, 기본키도 변경 불가.
• 영역 무결성(domain integrity) : 데이터 형태, 범위, 기본값, 유일성에 관한 제한이다. 주어진 속성값은 그 속성이 정의된 도메인에 속한 값이어야 한다.
  ex) 값이 0 이상, YN값 준수여부, 기본값은 1등
• 비즈니스 무결성(business integrity) : 사용자의 업무 규칙에 따른 비즈니스적인 제약 조건이다.
  ex) 제약조건, default, trigger 등의 사용자 정의

2. 데이터 무결성 강화 방법

• 애플리케이션(Application)의 로직 : 데이터를 조작하는 프로그램 내에서 데이터 생성, 수정, 삭제시 무결성 조건을 검증하는 코드를 추가
  • 장점 : 사용자 정의같은 복잡한 무결성 조건을 구현
  • 단점 : 소스코드에 분산되어 관리의 어려움이 있음. 개별적으로 시행되므로 적정성 검토에 어려움
• 트리거(Trigger) : 통합 관리가 가능, 복잡한 요건 구현 가능
•  제약 조건(Constraint)
  • 장점
    1) 통합관리가 가능, 간단한 선언으로 구현 가능
    2) 변경이 용이하고, 유효/무효 상태 변경이 가능
    3) 원칙적으로 잘못된 데이터 발생을 막을 수 있음
  • 단점 : 복잡한 제약조건 구현이 불가능. 예외적인 처리가 불가능

※ LOCK은 아님!! LOCK은 병행성 제어(동기성) 기법이다.