[10분 테코톡] 우기의 MySQL 아키텍처

https://youtu.be/vQFGBZemJLQ

MySQL 아키텍처 : MySQL 접속 클라이언트 --- MySQL 엔진 --(핸들러 API)-- MySQL 스토리지 엔진 --- 운영체제/하드웨어

  

<쿼리 실행 과정>

(쿼리 캐시)

- SQL 실행 결과를 메모리에 캐싱하는 역할

- 동일 SQL 실행 시 이전 결과 즉시 반환

- 테이블의 데이터가 변경되면 캐싱된 데이터 삭제 필요(동시 처리 성능 저하) => MySQL 8.0부터 완전히 제거됨

쿼리 파서

- SQL 문장을 토큰으로 쪼개서 트리(Parse Tree)로 만듦, 이 과정에서 쿼리 문장의 기본 문법 오류 체크

전처리기

- Parse tree를 기반으로 SQL의 문장 구조를 체크

- Parse tree의 토큰이 유효한지 체크

옵티마이저

- SQL 실행을 최적화해서 실행 계획을 수립

- 규칙 기반 최적화 : 옵티마이저에 내장된 우선순위에 따라 실행 계획 수립

- 비용 기반 최적화 : 작업의 비용과 대상 테이블의 통계 정보를 활용해서 실행 계획 수립

스토리지 엔진(핸들러)

- 쿼리 실행 엔진이 요청하는 대로 데이터를 디스크로 저장하고 읽음

- 핸들러 API에 의해 동작

- 플러그인 형태로 제공 => 사용자는 원하는 스토리지 엔진을 선택하여 사용할 수 있음

  

MyISAM 스토리지 엔진

- 클러스터링/트랜잭션/외래키 지원 X

- 테이블 단위 잠금 => 동시 처리에 불리함

- 키 캐시 사용(인덱스 정보만 버퍼링)

- 전문 검색, 공간 좌표 검색 기능 지원

  

InnoDB 스토리지 엔진

1. PK에 의한 클러스터링

- 레코드를 PK 순으로 정렬하여 저장

- PK 인덱스 자동 생성

- PK를 통해서만 레코드 접근 가능

- PK를 통한 범위 검색이 매우 빠름

- but 클러스터링 때문에 쓰기 성능 저하

2. 트랜잭션 지원(MVCC, REDO 로그 & UNDO 로그, 레코드 단위 잠금)

3. 버퍼풀 : 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐싱해두는 공간

- 데이터 캐싱 => 인덱스 정보와 데이터 파일을 메모리에 캐싱, 페이지 단위로 테이블 데이터를 관리, 페이지 교체 알고리즘으로 LRU 사용

- 쓰기 지연 버퍼 => 변경된 데이터를 버퍼풀에 모았다가 한 번에 디스크에 기록, JPA 영속성 컨텍스트의 쓰기 지연 SQL 저장소와 비슷

4. 어댑티브 해시 인덱스 : 인덱스 키와 페이지의 주소값 쌍으로 구성된 인덱스

- 페이지에 빠르게 접근하기 위한 해시 자료구조 기반 인덱스

- 자주 요청되는 페이지에 대해 InnoDB가 자동으로 생성하는 인덱스