1. 구조적, 집합적, 선언적 질의 언어
SQL : 'Strucetured Query Language'
말 그대로 구조적 질의 언어이다
오라클 PL/SQL, SQL Server T-SQL처럼 절차적 프로그래밍 기능을 구현할 수 있는 확정 언어도 제공하지만, SQL은 기본적으로 구조적이고 집합적이고 선언적인 질의 언어이다
원하는 결과 집합을 구조적, 집합적으로 선언하지만,
그 결과집합을 만드는 과정은 절차적일 수밖에 없다
즉, 프로시저가 필요하다
그런 프로시저를 만들어 내는 DBMS 내부 엔진이 바로 SQL 옵티마이저이다
(옵티마이저가 프로그래밍을 대신해 주는 셈이다)
DBMS 내부에서 프로시저를 작성하고 컴파일해서 실행 가능한 상태로 만드는 전 과정을 SQL 최적화라고 한다
2 SQL 최적화
세부적인 처리 과정을 설명할 목적이 아니라면 SQL 파싱과 최적화는 나눌 필요는 없음
그냥 두 개를 포함해서 SQL 최적화라고 한다
SQL 파싱
사용자로부터 SQL을 전달받아,
가장 먼저 SQL 파서(Parser)가 파싱을 진행한다
SQL 파싱을 요약하면,
파싱 트리 생성 : SQL 문을 이루는 개별 구성요소를 분석해서 파싱 트리를 생성한다
Syntax 체크 : 문법적 오류가 없는지 확인한다 (사용할 수 없는 키워드나 누락된 키워드 등)
Semantic 체크 : 의미상 오류가 없는지 확인한다 (존재하지 않는 테이블 또는 컬럼, 권한 문제 등)
SQL 최적화
옵티마이저가 이 역할을 맡는다
미리 수집한 시스템 및 오브젝트 통계정보를 바탕으로 다양한 실행경로를 생성해서 비교한 후, 가장 효율적인 하나를 선택한다
데이터베이스 성능을 결정하는 가장 핵심적인 엔진이다
로우 소스 생성
로우 소스 생성기가 이 역할을 맡는다
SQL 옵티마이저가 선택한 실행경로를 실제 실행 가능한 코드 또는 프로시저 형태로 포맷팅 하는 단계다
3. SQL 옵티마이저
SQL 옵티마이저는 사용자가 원하는 작업을 가장 효율적으로 수행할 수 있는
최적의 데이터 액세스 경로를 선택해 주는 DBMS의 핵심 엔진이다
옵티마이저의 최적화 단계를 간단히 살펴보자
1. 사용자로부터 전달받은 쿼리를 수행하는 데 후보군이 될만한 실행계획들을 찾아낸다
2. 데이터 딕셔너리에 미리 수집해 둔 오브젝트 통계 및 시스템 통계정보를 이용해 각 실행계획의 예상비용을 산정한다
3. 최저 비용을 나타내는 실행계획을 선택한다
4. 실행계획과 비용
DBMS에는 'SQL 실행경로 미리보기' 기능이 있다
바로 실행계획(Execution Plan)이다
SQL 옵티마이저가 생성한 처리절차를 사용자가 확인할 수 있게 트리 구조로 표현한 것이 실행계획이다
예상과 다른 방식으로 처리된다면 실행경로를 변경할 수 있다
옵티마이저가 특정 실행계획을 선택하는 근거는 무엇일까?
바로 비용(Cost)이다
쿼리를 수행하는 동안 발생한 것으로 예상되는 I/O 횟수 또는 예상 소요시간을 표현한 값이다
Cost는 어디까지나 예상치다
옵티마이저가 여러 통계정보를 활용해서 계산해 낸 값이다
실측치가 아니므로 실제 수행할 때 발생하는 I/O 또는 시간과 많은 차이가 난다
5. 옵티마이저 힌트
SQL 옵티마이저도 대부분 좋은 선택을 하지만, 완벽하지 않다
SQL이 복잡할수록 실수할 가능성도 크다
개발자가 직접 더 효율적인 액세스 경로를 찾을 수 있다
이럴 때 힌트를 이용해 데이터 액세스 경로를 바꿀 수 있다
SELECT /*+ INDEX(A 고객_PK) */
고객명, 연락처
FROM 고객 A
WHERE 고객ID = '00001'주의사항이 있다
힌트 안에 인자를 나열할 땐 ',(콤마)'를 사용할 수 있지만, 힌트와 힌트 사이에 사용하면 안 된다
테이블을 지정할 때 스카마명까지 명시하지 말자
FROM 절 테이블명 옆에 ALIAS를 지정했다면, 힌트에서도 반드시 ALIAS를 사용하자
댓글