MySQL 엔진 아키텍쳐
MYSQL의 전체 구조
1. MySQL 엔진
- 클라이언트의 접속, 쿼리 요청 처리하는 커넥션 헨들러, SQL 파서, 실행 계획 처리를 도와주는 옵티마이저로 구성
- 요청된 SQL 문장을 분석하거나 최적화 하는 MySQL의 주요요소.
2. 스토리지 엔진
- 실제 데이터를 디스크에 저장하거나 읽어오는 역할
3. 핸들러 API
- MySQL의 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽어야 하는 경우, 스토리지 엔진에 요청을 하게 되는데 이 요청을 핸들러 요청이라고 여기서 사용되는 API를 핸들러 API라고 한다.
SHOW GLOBAL STATUS LIKE 'Handler%';를 통해 확인 가능
MySQL 엔진은 사람, 스토리지 엔진은 자동차, 핸들러 API는 운전대와 같은 역할.
MySQL 쓰레딩 구조
MySQL은 크게 포그라운드 쓰레드와 백그라운드 쓰레드로 나눠진다.
1. 포그라운드 쓰레드
포그라운드 쓰레드는 MySQL에 접속한 사용자의 요청 쿼리를 처리한다. 커넥션이 끝나게 되면, 포그라운드 쓰레드는 쓰레드 캐시로 돌아가게 된다.
2. 백그라운드 쓰레드
여러가지 작업이 백그라운드 쓰레드에서 실행된다.
- 인서트 버퍼 병합 쓰레드
- 잠금이나 데드락 모니터링 쓰레드
- InnoDB 버퍼 풀의 데이터를 디스크에 기록하는 쓰레드
- 데이터를 버퍼로 가져오는 쓰레드
- 로그를 디스크에 기록하는 쓰레드
메모리 할당 및 사용 구조
MySQL에서는 메모리 영역이 크게 글로벌 영역과 세션 메모리 영역으로 나뉜다.
1. 글로벌 메모리 영역
클라이언트 쓰레드와 무관하게 단 1개의 메모리 공간.
2. 로컬(세션) 메모리 영역
클라이언트 요청에 따른 쓰레드의 메모리 영역 생성
플러그인 스토리지 엔진 모델
SHOW PLUGINS; 를 통해 플러그인을 확인할 수 있는데, 스토리지 엔진을 갈아끼울 수 있다. 스토리지 엔진 뿐만 아니라 비밀번호 검증, 커넥션 제어, 인증 등등의 플러그인도 존재한다.
컴포넌트
MySQL 8.0부터 컴포넌트 아키텍쳐 지원. 기존의 플러그인은 플러그인끼리 통신 불가나 서버의 변수나 함수를 직접 호출해 안전하지 않아 컴포넌트를 제공. INSTALL COMPONENT 를 통해 설치 가능. 자세한 사항은 MySQL 매뉴얼 참조.
쿼리 실행 구조
1. 쿼리 파서
쿼리 문장을 토큰화하여 트리형태로 만듬. 문법 오류 체크. 컴파일러 느낌.
2. 전처리기
쿼리 문장의 구조적인 문제점 파악. 테이블 이름, 칼럼 이름, 내장 함수 존재 여부와 접근 권한 체크
3. 옵티마이저
DBMS의 두뇌. 쿼리 문장을 저렴한 비용으로 빠르게 처리할지 결정하는 역할
4. 실행 엔진 (쿼리 실행기)
실행 엔진은 만들어진 계획대로 각 핸들러에게 요청해서 받은 결과를 사용자에게 넘기거나, 또 다시 핸들러에게 다시 넘겨 입력을 연결하는 역할을 함.
5. 핸들러 (스토리지 엔진)
실제 디스크 저장 및 읽어오는 담당.
쿼리 캐시
쿼리 캐시는 SQL의 결과를 메모리 저장해두었는데, 동시 처리와 같은 부분에서 버그가 많이 터져 8.0 버젼에서 사라짐.
쓰레드 풀
Percona Server에서 쓰레드 풀 플러그인 라이브러리를 설치하면 사용 가능하다.
사용자의 요청을 처리하는 쓰레드 갯수를 줄여 동시 처리 요청이 많더라도 MySQL의 CPU가 제한된 쓰레드만 처리하도록 하는 것. 적절히 유도한다면 당연히 컨텍스트 스위치 비용이 하락할 것임. 하지만 잘 적용해야 한다.
Percona Server에서는 우선순위 큐를 이용해 먼저 실행할 쿼리나 트랜잭션을 처리할 수 있는 기능도 제공한다.
트랜잭션 지원 메타데이터
MySQL 8.0 부터는 테이블의 구조 정보와 스토어드 프로그램의 코드 관련 정보를 모두 InnoDB에 넣었다. InnoDB가 시스템 테이블과 테이블 구조 정보를 모두 갖게 되면서 (mysql.ibd) 테이블을 생성하거나 변경할 때 완전 성공이나 실패 이외에는 기록하지 않게 되어, 테이블이 깨지는 경우를 없앴다. InnoDB의 경우는 이렇지만, MyISAM이나 CSV의 스토리지 엔진은 SDI파일을 통해 처리한다.
