SQL 성능 향상을 위한 공부: 1-3) 쿼리 평가엔진에 대하여

쿼리평가 엔진이란?

- 사용자로부터 SQL 구문을 입력받아 분석하고

- 데이터 접근 절차(실행 계획)를 결정하고 실행하는 모듈이다.

 

 

쿼리평가 엔진이 쿼리를 처리하는 흐름

쿼리평가 엔진은 사용자로부터 SQL을 입력받은 후, 크게 3단계에 걸쳐 SQL을 처리한다.

 

stage 1. Parser

- Parsing: 입력받은 SQL 문(자연어)을 Parse Tree로 번역

- Transformation Process: Parse Tree를 전달받아 Query Tree로 번역

↓

stage 2. Optimizer

시스템 카탈로그에 있는 테이블의 통계 정보를 바탕으로 다양한 실행 계획을 생성한 후, 가장 효율적으로 동작하는 실행 계획을 선택

↓
stage 3. Executor (plan evaluation)

선택한 실행 계획 순서대로 데이터를 처리.

 

1. 파서(parser)

(1) parsing

: 파스(parse: 구문 분석)를 한다. 즉, SQL 구문을 입력받으면 이를 분석하여 parse tree 라는 것을 출력한다. 분석하는 과정에서 SQL 구문의 문법 오류를 판단한다. 

 

(2) Transformation Process

: 위에서 전달받은 Parse Tree를 기반으로 여러 조건을 확인하는 단계다. 아래 내용들에 대해 검증을 끝내면, 해당 내용을 담아 Query Tree를 생성한 후 다음 단계로 전달한다.

 

- Table & Column 존재하는지 확인
- 연산자 및 데이터 타입을 확인하며, 적용 가능한 연산인지 확인

 

 

 

2. 옵티마이저(optimizer)

SQL 쿼리를 어떻게 실행할지 결정하는 중요한 모듈. 즉, 쿼리를 어떤 순서로, 어떤 인덱스를 사용해서, 어떤 방식으로 조인을 수행할지를 최적화된 실행 계획(Execution Plan)을 만든다.

 

(1) 실행 계획(plan) 생성

: 인덱스 유무, 데이터 분산 또는 편향 정도, DBMS 내부 매개변수 등의 조건을 고려해서 선택 가능한 많은 실행 계획을 작성한다. 실행 계획을 세울 때, 카탈로그 매니저(catalog manager)는 시스템 카탈로그의 중요한 정보를 옵티마이저에 제공한다. 카탈로그란 DMBS의 내부 정보를 모아놓은 테이블로, 테이블 또는 인덱스의 통계 정보가 저장되어 있다. 카탈로그 정보를 쉽게 '통계 정보' 라고 부르기도 한다.

 

<카탈로그에 포한되어 있는 통계 정보>

- 각 테이블의 레코드 수

- 각 테이블의 필드 수와 필드의 크기

- 필드의 카디널리티(값의 개수)

- 필드값의 하스토그램

- 필드 내부에 있는 NULL 수

- 인덱스 정보

 

옵티마이저는 이러한 정보를 활용함으로서 실행 계획을 만든다. 하지만 옵티마이저가 완벽한 것은 아니다. 실제로 옵티마이저가 최적의 플랜을 선택하지 않는 경우도 꽤 많다고 한다. 옵티마이저가 실패하는 몇 가지 패턴이 있는데, '통계 정보'가 부족한 경우가 대표적인 원인으로 꼽힌다. 

 

(2) 비용(cost) 계산 및 선택

: 여러 실행 계획들의 비용을 계산한 후 비교하여 가장 낮은 비용을 가진 실행 계획을 선택한다.

 

 

[참고] 옵티마이저의 동작 방식 주요 분류
(옵티마이저가 어떤 원칙과 기준으로 실행 계획을 선택하는가에 따른 분류)

1. Rule-Based Optimizer (RBO): 미리 정의된 규칙 기반 (과거 방식)
2. Cost-Based Optimizer (CBO): 통계 정보를 기반으로 비용 계산 → 현재 대부분 사용

위 2개의 방식이 가장 널리 알려진 주요 분류이며, 실제 DBMS 구현에서도 거의 이 두 가지 원칙 중 하나 또는 그 조합으로 옵티마이저가 동작한다. 하지만 현실은 조금 더 복합적이고, 몇 가지 하위 방식이나 진화형이 존재한다.

 

 

 

3. 실행(executor) 및 플랜 평가(plan evaluation)

실행 계획이라는 것은 곧바로 DBMS가 실행할 수 있는 형태의 코드가 아니다. 오히려 인간이 읽기 쉽게 만들어진 문자 그대로의 '계획서'라고 볼 수 있다. 실행 계획을 읽고 수정 방안을 고려할 수도 있다. 

 

이렇게 최종적으로 하나의 실행 계획을 선택하면, 이후에 DBMS는 실행 계획을 절차적인 코드로 변환하고 데이터 접근을 수행한다.

 

 

 

 

[참고]

https://learn.microsoft.com/ko-kr/sql/relational-databases/query-processing-architecture-guide?view=sql-server-ver17

쿼리 처리 아키텍처 가이드 - SQL Server

 

 

https://ksh-coding.tistory.com/158

[PostgreSQL] 1. PostgreSQL 내부 구조 알아보기 (feat. 쿼리 처리 과정)

 

https://velog.io/@impala/DB-Query-Processing

[DB] Query Processing

 

https://jelong.tistory.com/entry/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%84%A4%EA%B3%84%EC%BF%BC%EB%A6%AC-%ED%8F%89%EA%B0%80-%EA%B8%B0%EC%B4%88Query-Evaluation-Basics

[데이터베이스 설계]쿼리 평가 기초(Query Evaluation Basics)

 

https://codenme.tistory.com/25

[db] query optimization