MySQL / MariaDB 기본 아키텍처 (쿼리 실행 과정)

해당 페이지에서는 MySQL / MariaDB 의 쿼리 기본 실행과정을 알아본다.

 

(참조페이지 및 그림출처)

rastalion.me/mysql-%EC%BF%BC%EB%A6%AC-%EC%8B%A4%ED%96%89-%EA%B5%AC%EC%A1%B0/

shashwat-creator.medium.com/mysqls-logical-architecture-1-eaaa1f63ec2f

 

해당 페이지를 보기 전 MySQL / MariaDB 엔진의 기본 아키텍처를 확인하고 오면 좋다.

 

2021.03.12 - [MySQL/아키텍처 및 내부 구조] - MySQL / MariaDB 기본 아키텍처 (Engine)

 

 

 

MySQL / MariaDB 는 내부적으로 클라이언트가 쿼리를 수행 시, 아래와 같은 개요로 처리 된다.

 

 

Query Cache

 

우선, 클라이언트가 쿼리를 수행시 제일 먼저 거치는 단계다. 이 공간은 클라이언트가 수행한 쿼리에 대한 결과값을 보관하는데 이후에 클라이언트가 쿼리를 수행했는데 이에 대한 결과값이 기존에 저장했던 값과 동일한 값을 반환한다면, 뒤의 과정들을 거치지 않고도 결과를 빠르게 반환 해 준다. query_cache_size 라는 파라미터로 공간을 조절 할 수 있으나, 이 변수를 변경시에는 기존에 보관하는 기록들을 모두 비워낸다.

 

Parser 

 

위의 Query Cache 에서 동일한 결과값을 반환하지 않는 쿼리로 확인 될 시, 그 다음으로 거치는 단계다. 여기서는 클라이언트가 작성한 SQL 구문이 MySQL / MariaDB 에서 사용 할 수 있는 SQL 구문 문법을 따르는지 확인하는 단계다. 즉, SELECT, INSERT 등에서 쓰는 문법을 정확하게 썼는지 점검한다. 또한 DB 내부적으로 해당 구문을 처리 할 수 있도록 구문 내용들을 DB 언어적으로 Tree 형태로 분리하면서 나눈다.

 

Preprocessor

 

위의 Parser 과정을 거쳐, 문법자체에 이상이 없다면 아래의 과정을 체크하는 영역이다.

 

- 사용하려는 쿼리의 문법에 이상이 없다면, 해당 쿼리가 작업 대상 테이블에서 수행 가능한 구문인지 확인한다.
(ex : 테이블 내 조회 쿼리가 조회 할 컬럼이 있는지 유무 등)

 

- 해당 쿼리를 사용하려는 유저가 수행 할 수 있는지에 대한 권한을 가지고 있는지 확인한다.

 

Query Optimizer

 

SQL 쿼리를 수행 시, 해당 쿼리를 효율적으로 수행 할 수 있도록 DB 내부 언어로 가공하는 영역이다. 효율적인 실행 계획을 세울 시, RDBMS 는 최적 성능 기반으로 계획하는 CBO (Cost-Based Optimization) 와 성능보다 설정된 실행 계획 기준 자체를 중시하는 RBO (Rule-Based Optimization) 중 하나를 사용한다. MySQL / MariaDB 는 CBO 를 기본으로 사용하며 (단 이는 옵티마이저가 분석 하는 쿼리의 성향에 따라 달라 질 수도 있다), 여기에서 산출하는 Cost 의 기본 단위는 4KB 1페이지의 데이터를 읽는데 소비하는 비용이다. 즉, 4KB 페이지의 데이터를 조회하는데 소비된 비용을 1 Cost 로 산출한다. (최근에는 서비스나 서버의 추가 세팅으로 추가로 소비되는 추가 비용을 합산하기도 한다)

DB 에서는 Last_query_cost 파라미터를 통하여 바로 전에 수행 한 쿼리의 소요 비용을 확인 할 수 있다.

MySQL Workbench 에서도 이를 시각적으로 볼 수 있다.

 

The execution plan

 

위의 옵티마이저를 통하여 만들어진 실행 계획이다. 일반적으로 RDBMS 는 실행 계획을 통한 쿼리를 수행하기 위하여 이진코드를 만드는데 MySQL / MariaDB 는 이 대신 트리구조 같이 일련의 실행계획 과정을 만들어 내어 엔진이 이를 통하여 순차적으로 진행하도록 한다.

 

The Query Execution Engine

 

위의 실행계획을 실제로 수행하는 영역이다. 위에서 만들어진 일련의 실행 과정을 거치면서 더 이상 실행을 위해 조회 할 데이터 row 가 없을때까지 계속 진행 되며, 이 때 조회를 하기 위해 실제 데이터를 보관하는 스토리지 엔진과 지속적으로 API Call 을 주고 받는다.