클라이언트로부터 접속 및 쿼리 요청을 처리하는 커넥션 핸들러 + SQL 파서 및 전처리기 + 쿼리의 최적화된 실행을 위한 옵티마이저 이렇게 이루어져있다.
분석 및 최적화하는 역할 수행
총 1개
스토리지 엔진
실제 데이터를 디스크 스토리지에 저장 혹은 읽어오는 역할 담당
여러개 동시 사용 가능
핸들러 API
MySQL 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽어야 할 때 각 스토리지 엔진에 쓰기 또는 읽기를 요청. 이러한 요청을 핸들러 요청이라고 함. 그 때 사용되는 API를 핸들러 API라고 함.
MySQL 스레딩 구조
MySQL 서버는 프로세스 기반이 아닌 스레드 기반으로 작동.
포그라운드(FOREGROUND)와 백그라운드(BACKGROUND) 스레드로 구분 가능.
44개의 스레드가 가동 되는데 그중 'thread/sql/one_connection' 스레드만 실제 사용자의 요청을 처리하는 포그라운드 스레드.
포그라운드 스레드(클라이언트 스레드)
최소한 MySQL 서버에 접속된 클라이언트 수만큼 존재. 주로 각 클라이언트 사용자가 요청하는 쿼리 문장 처리.
커넥션 종료시 해당 커넥션 담당하던 스레드는 다시 스레드 캐시로 되돌아감. -> 이미 일정 개수 이사 스레드 캐시에 있다면 돌아가지 않고 종료 시킴.
백그라운드 스레드
InnoDB의 여러 작업이 백그라운드로 실행됨.(로그를 디스크로 기록, 인서트 버퍼 병합 스레드, 데이터를 버퍼로 읽어 오는 스레드 등)
그 중에서 중요한 것은 버퍼의 데이터를 디스크로 내려쓰는 작업을 처리하는 쓰기 쓰레드.
사용자 요청 처리시 데이터 쓰기 작업은 지연(버퍼링)될 수 있지만, 데이터 읽기 작업은 절대 지연될 수 없음.
쿼리 실행 구조
쿼리 파서
사용자 요청으로 들어온 쿼리 문장을 토큰(MySQL이 인식할 수 있는 최소 단위의 어휘나 기호)으로 분리해 트리 형태의 구조로 만들어 내는 작업
이 과정에서 쿼리의 기본 문법 오류 발견 및 사용자에게 메시지 전달
전처리기
파서 과정에서 만들어진 트리를 기반으로 쿼리 문장에 구조적 문제점 확인. 테이블 이름, 칼럼이름, 접근 권한등 확인
옵티마이저
사용자의 요청으로 들어온 쿼리 문장을 저렴한 비용으로 가장 빠르게 처리할지 경정하는 역할(두뇌)
실행엔진
손과 발. 실행 엔진은 핸들러에게 임시 테이블 만들라거나 핸들러에게 where절에 맞는 레코드를 읽어오라고 함. 즉 일련의 과정을 거쳐 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 역할 수행
핸들러(스토리지 엔진)
서버 가장 밑단에서 실행 엔진의 요청에 따라 데이터를 디스크로 저장하고 디스크로부터 읽어 오는 역할 담당. 결국 스토리지 엔진을 의미
쿼리 캐시
빠른 응답을 필요로 하는 웹 기반의 응요 프로그램에서 중요한 역할. 쿼리 캐시는 SQL의 실행 결과를 메모리에 캐시하고 동일 SQL 쿼리가 실행되면, 테이블로 가지 않고 즉시 결과 반환.
하지만, 쿼리 캐시는 테이블의 데이터 변경시 캐시에 저장된 결과 중 변경된 테이블과 연관된 모든 것을 삭제. 이는 심각한 동시 처리 성능 저하 유발. 현재는 제거된 것으로 많은 버그의 원인으로 지목.
스레드풀
사용자의 요청을 처리하는 스레드 개수를 줄여서 동시 처리되는 요청이 많다 하더라도 서버의 CPU가 제한된 개수의 스레드 처리에만 집중할 수 있께 하여 서버의 자원 소모를 줄이는 것이 목적.
실제로 스레드 풀로 인한 엄청난 성능 향상은 드물었다. 이유는 동시에 실행 중인 스레드들을 CPU가 최대한 잘 처리해낼 수 있는 수준으로 줄여서 빨리 처리하게 하는 기능이라 스케줄링 과정에서 CPU 시간을 제대로 확보하지 못하는 경우 쿼리 처리가 더 느려지는 경우도 존재.