MySQL 아키텍처

해당 게시물은 'Real MySQL 8.0'라는 책을 참고해서 작성했습니다.

👣 개요

MySQL 내부에서 어떤 방식으로 작동하는지를 알기위해 해당 게시물을 작성함.

👣 MySQL 엔진 아키텍처

MySQL은 다른 DBMS에 비해 아키텍처가 매우 독특하다.

👣 MySQL 엔진

해당 부분은 커넥션 핸들러, SQL 파서, 옵티마이저 등등이 속해 있다.
주로 SQL 문장을 분석 및 최적화 하는 등의 두뇌 역할을 수행.

MySQL은 표준 SQL(ANSI SQL) 문법을 지원하기 때문에 타 DBMS와 호환 가능하다.

👣 스토리지 엔진

실제 데이터를 저장하고 DISK에서 조회하는 부분.

👣 핸들러 API

MySQL 엔진의 쿼리 실행기에서 스토리지 엔진에게 쓰기 or 읽기 요청을 보내는데
이 때 사용하는 API를 핸들러 API라고 한다.

 

👣 MySQL 스레딩 구조

MySQL은 프로세스 기반이 아닌 스레드 기반으로 작동한다.

MySQL은 스레드를 2 가지로 분류할 수 있다.

1. Foreground Thread
클라이언트 스레드라고도 불림.
주로 사용자가 요청하는 쿼리 문장을 처리하는 스레드.
각 클라이언트 연결마다 포그라운드 스레드가 할당
사용자 요청이 완료될 때까지 계속 실행되며, 사용자의 쿼리가 복잡하거나
시간이 오래 걸릴 경우 해당 스레드는 장시간 실행될 수 있습니다
MySQL의 데이터 버퍼나 캐시로부터 데이터를 가져오는 역할까지 수행하지만,
만약 캐시에 데이터가 없다면 직접 디스크를 탐색하는데 
이런 부분까지는 수행하지 않고 Background Thread로 넘긴다.

2. Background Thread
다양한 부분을 처리하지만 주로 디스크로 데이터를 기록하는 작업[INSERT, UPDATE, DELETE] 등의 작업을 수행한다.
때문에 InnoDB의 경우 데이터가 실제로 파일에 저장될 때까지 기다릴 필요가 없다.
이런 기능을 버퍼링 기능이라고 한다.

👣 MySQL 메모리 할당 및 사용 구조

👣 글로벌 메모리 영역

모든 스레드에 의해 공유되는 메모리 영역.
클라이언트 스레드 수와 무관하게 1개의 메모리 공간만 할당됨.

👣 로컬 메모리 영역

클라이언트 스레드의 처리를 위한 메모리 영역.
클라이언트 스레드당 하나씩 할당된다.
다른 스레드와 전혀 공유되지 않는다.

👣 쿼리 실행 구조

👣 쿼리 파서

사용자 요청을 Token으로 분리해 Tree 구조로 만드는 작업.
기본 문법 오류를 이 과정에서 감지함.

👣 전처리기

Parser Tree 기반으로 쿼리 문장에 구조적 문제점을 확인.
실제로 존재하지 않거나 권한상 사용할 수 없는 토큰은 이 단계에서 걸러짐.

👣 옵티마이저

쿼리를 가장 빠르게 적은 비용으로 어떻게 처리할 지를 결정하는 부분.

👣 실행 엔진

실행 엔진은 데이터베이스 서버에 설치된 각 핸들러를 선택하고 관리하는 역할을 수행합니다.
실행 엔진은 각 핸들러의 특성과 데이터베이스 전체적인 처리 방식을 조정하고 관리하는 역할을 합니다.

👣 핸들러 - 스토리지 엔진

실행 엔진의 요청에 따라 데이터를 실제 디스크로 저장하고 읽는 역할을 담당한다.

 

👣 쿼리 캐시

MySQL 8.0 이전 버전에서는 빠른 응답을 위한 장치로서 쿼리 캐시 기능을 지원했다.
동일한 SQL 쿼리가 실행되면 테이블을 거치지 않고 메모리 캐시에서 즉시 결과를 도출했다.

하지만 이것은 동일한 쿼리여도 데이터의 변화가 생기면 해당 캐시는 효용성을 잃어버리기 때문에
오히려 캐시를 지워야 하는 작업으로 인해 성능 저하를 야기했고 또한 수많은 버그의 원인이었다.

때문에 MySQL 8.0 이후 버전은 해당 쿼리 캐시가 완전히 삭제되었다.

 

👣 스레드 풀

MySQL 서버 엔터프라이즈 에디션은 스레드 풀 기능을 제공한다.
하지만 커뮤니티 에디션은 지원하지 않는다.

스레드 풀이란, 요청마다 스레드를 생성하는 것이 아니라
미리 스레드를 만들어 놓고 요청 때 할당하는 방식이다.
이런 방식은 스레드 생성 비용을 줄여줘 더 빠른 처리 시간을 달성할 수 있고
불필요한 컴퓨터 자원을 줄일 수 있다.