출처 - https://github.com/jmxx219/CS-Study (opens in a new tab)

MySQL 엔진 아키텍처

MySQL 전체 구조

• MySQL 서버는 크게 MySQL 엔진과 스토리지 엔진으로 구성된다.
  • MySQL 엔진은 사람의 머리 역할을 담당하고, 스토리지 엔진은 손과 발의 역할을 담당한다.

✔️ MySQL 엔진

• SQL을 분석하거나 최적화하는 등 DBMS의 두뇌에 해당하는 처리를 수행한다.
• 커넥션 핸들러(클라이언트로부터의 접속 및 쿼리 요청을 처리), SQL 파서, 전처리기, 옵타마이저, 캐시 & 버퍼 등등이 중심을 이룬다

✔️ 스토리지 엔진

• 실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 데이터를 읽어오는 MySQL의 손발 역할을 전담한다.
• MySQL 엔진은 하나지만, 이와 다르게 스토리지 엔진은 여러 개를 동시에 사용할 수 있다.
• MySQL 엔진의 핸들러 API를 통해 호출되며, 대표적으로 InnoDB, MyIsam, Memory 등 스토리지 엔진이 존재한다.

  CREATE TABLE test(fd1 INT, fd2 INT) ENGINE=INNODB;
  • 테이블이 사용할 스토리지 엔진을 지정하면, 이후 해당 테이블의 모든 읽기 작업이나 변경 작업은 스토리지 엔진이 수행한다.
  • MySQL InnoDB 스토리지 엔진 참고 (opens in a new tab)

✔️ 커넥션 핸들러(핸들러 API)

• MySQL 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽어야 할 때는 각 스토리지 엔진으로 쓰기 또는 읽기를 요청하는데, 이를 핸들러 요청이라고 한다.
  • 여기서 사용되는 API를 핸들러 API라고 한다.
• InnoDB 스토리지 엔진도 핸들러 API 를 이용해 MySQL 엔진과 데이터를 주고 받는다.

MySQL 스레딩 구조

• MySQL 서버는 프로세스 기반이 아니라 스레드 기반으로 동작하며, 크게 포그라운드 스레드와 백그라운드 스레드로 구분할 수 있다.

✔️ 포그라운드 스레드(클라이언트 스레드)

• 최소한 MySQL 서버에 접속된 클라이언트 수만큼 존재하며, 주로 각 클라이언트 사용자가 요청하는 쿼리 문장을 처리한다.
• 클라이언트 사용자가 작업을 마치고 커넥션을 종료하면 해당 커넥션을 담당하던 스레드는 다시 스레드 캐시(Thread Cache)로 되돌아 간다.
  • 이 때 이미 스레드 캐시에 일정 개수 이상의 대기 중인 스레드가 있으면, 스레드 캐시에 넣지 않고 스레드를 종료시켜 일정 개수의 스레드만 스레드 캐시에 존재하게 한다.
• 포그라운드 스레드는 데이터를 MySQL의 데이터 버퍼나 캐시에서 가져오며, 버퍼나 캐시에 없는 경우에는 직접 디스크의 데이터나 인덱스 파일로부터 데이터를 읽어와서 작업을 처리한다.
  • MyISAM 테이블은 디스크 쓰기 작업까지 포그라운드 스레드가 처리
  • InnoDB 테이블은 데이터 버퍼나 캐시까지만 포그라운드 스레드가 처리하고, 나머지 작업은 백그라운드 스레드가 처리

✔️ 백그라운드 스레드

• 사용자의 요청을 처리하는 도중 데이터 쓰기 작업은 지연되어 처리될 수 있지만, 읽기 작업은 절대 지연될 수 없다.
• 일반적인 상용 DBMS에는 대부분 쓰기 작업을 버퍼링해서 일괄 처리하는 기능이 탑재되어 있으며, InnoDB 또한 이러한 방식으로 처리한다.
  • 이러한 이유로 InnoDB에서는 쓰기 쿼리로 데이터가 변경되는 경우, 데이터가 디스크의 데이터 파일로 완전히 저장될 때까지 기다리지 않아도 된다.
  • MyISAM은 그렇지 않고 사용자 쓰레드가 쓰기 작업까지 함께 처리하도록 설계되어 있다.

메모리 할당 및 사용 구조

• MySQL에서 사용 되는 메모리 공간은 크게 글로벌 메모리 영역과 로컬 메모리 영역으로 구분 할 수 있다.

✔️ 글로벌 메모리 영역

• 글로벌 메모리 영역의 모든 메모리 공간은 MySQL 서버가 시작되면서 운영체제로부터 할당된다.
  • 실제로는 엄청 복잡하지만, 단순하게 MySQL 시스템 변수로 설정해 둔 만큼 운영체제로부터 메모리를 할당받는다고 생각하면 된다.
• 클라이언트 스레드의 수와 무관하게 하나의 메모리 공간만 할당된다.
  • 필요에 따라 2개 이상의 메모리 공간을 할당받을 수도 있지만 클라이언트 스레드 수와는 무관하다.

✔️ 로컬 메모리 영역

• MySQL 서버상에 존재하는 클라이언트 스레드가 쿼리를 처리하는데 사용하는 메모리 영역이다.
  • 클라이언트 MySQL 서버에 접속하면 MySQL 서버에서는 클라이언트 커넥션으로부터의 요청을 처리하기 위해 스레드를 하나씩 할당하는데, 클라이언트 스레드가 사용하는 메모리 공간이라고해서 클라이언트 메모리 영역이라고도 한다.
  • 또한, 서버와의 커넥션 섹션이라고도 하기 때문에 로컬 영역이라고 표현한다.
• 로컬 메모리는 각 클라이언트 스레드별로 독립적으로 할당되며, 절대 공유되어 사용되지 않는다.
• 각 쿼리마다 용도별로 필요할 때만 공간이 할당되고 필요하지 않은 경우에는 MySQL이 메모리 공간을 할당조차도 하지 않을 수도 있다.
• 또한, 커넥션이 열려있는 동안 계속 할당된 상태로 남아있는 공간(커넥션 버퍼나 결과 버퍼)도 있으며, 그렇지 않고 쿼리를 실행하는 순간만 할당하는 소트 버퍼나 조인 버퍼가 있다.

쿼리 실행 구조(쿼리 처리 절차)

• 쿼리를 실행하는 관점에서 MySQL 구조를 기능별로 나눌 수 있다.

✔️ 쿼리 파서

• SQL 요청을 토큰(MySQL이 인식할 수 있는 최소 단위의 어휘나 기호)로 분리해 트리 형태의 구조로 만들어내는 작업을 수행한다
• 쿼리의 문법 오류는 이 과정에서 발견되고, 오류가 있을 경우 사용자에게 오류 메시지를 전달하게 된다.

✔️ 전처리기

• 이전의 파서 과정에서 만들어진 트리를 기반으로 쿼리 문장에 구조적인 문제점이 있는지 확인한다.
• 이후 토큰을 테이블 이름, 컬럼 이름 또는 내장 함수와 같은 개체를 매핑해 개체 존재 여부와 개체 접근 권한을 확인하는 과정을 수행한다
  • 실제로 존재하지 않거나 권한 상 사용할 수 없는 개체의 토큰은 이 단계에서 걸러진다.

✔️ 옵티마이저

• 쿼리 문장을 저렴한 비용으로 가장 빠르게 처리 할지를 결정하는 역할과 실행계획을 작성을 담당하며, DBMS의 두뇌에 해당한다.
• 대표적인 종류
  • RBO(Rule-Based Optimizer): 우선 순위에 따라서 스코어를 매겨서 실행 계획을 수립한다.
  • CBO(Cost-Based Optimizer): 수행 가능한 방법의 비용 과 테이블 통계 정보를 통한 비용에 따른 실행 계획을 수립한다.
• MySQL 에서는 CBO를 사용하며, 최근의 대부분 RDB에서의 기본 옵티마이저는 CBO를 사용하고 있다.

✔️ 실행 엔진(쿼리 실행기)

• 옵티마이저가 계획한대로 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 손발 역할을 수행한다.
• 실행 엔진은 만들어진 실행 계획대로 각 핸들러에게 요청을 하게 되고, 또 다시 받은 결과를 또 다른 핸들러를 요청하여 입력으로 연결하는 역할을 한다.

✔️ 핸들러(스토리지 엔진)

• MySQL 서버의 가장 밑단에서 MySQL 실행 엔진의 요청에 따라 데이터를 디스크로 저장하고 디스크로부터 읽어 오는 역할을 담당한다.
• 핸들러는 결국 스토리지 엔진을 의미하며, InnoDB의 테이블일 경우 핸들러는 InnoDB 스토리지 엔진이 된다.