MySQL 아키택처

• MySQL 엔진: 사람으로 비유하면 판단과 명령을 하는 두뇌라 생각할 수 있음
  구성 요소

  1. 쿼리 파서

     • SQL을 파싱하여 Syntax Tree를 만들고 이 과정에서 문법 오류 검사가 이루어짐
     • https://observablehq.com/@john-guerra/sql-query-visualizer
     • 위 주소에서 SQL의 Syntax Tree가 어떻게 만들어지는 확인 가능

  2. 전처리기

     • 쿼리파서에서 만든 Tree를 바탕으로 전처리 시작
     • 테이블이나 컬럼 존재 여부, 접근권한 등 Semantic 오류 검사

  3. 옵티마이저:

     • 쿼리를 처리하기 위한 여러 방법들을 만들고, 각 방법들의 비
       용정보와 테이블의 통계정보를 이용해 비용을 산정
     • 테이블 순서, 불필요한 조건 제거, 통계정보를 바탕으로 전략을 결정 (실행 계획 수립)
     • 옵티마이저가 어떤 전략을 결정하느냐에 따라 성능이 많이 달라진다.
     • 가끔씩 성능이 나쁜 판단을 해 개발자가 힌트를 사용해 도움을 줄 수 있다
     • explain 명령어를 통해서 옵티마이저의 선택을 확인 할 수 있음

  4. 쿼리 실행기:

     • 옵티마이저가 선택한 방법으로 스토리지 엔진에 요청하는 역할을 수행
     • Handler API를 사용
     • 스토리지 엔진에 요청하는 걸 헨들러 요청이라고 함
     • Handler API를 만족하는 스토리지 엔진을 구현 할 수 있다면 구현한 스토리지 엔진을 추가 하여 사용 할 수 있다.

쿼리파서, 전처리기는 컴파일 과정과 매우 유사하다.
하지만 SQL은 프로그래밍 언어처럼 컴파일 타임때 검증 할 수 없어 매번 구문 평가를 진행

• 스토리지 엔진: 명령을 수행하는 팔 다리라 생각할 수 있음
• 디스크에서 데이터를 가져오거나 저장하는 역할
• MySQL 스토리지 엔진은 플러그인 형태로 Handler API만 맞춘다면 직접 구현해서 사용할 수 있다.
• InnoDB, MyIsam 등 여러개의 스토리지 엔진이 존재
• 8.0대 부터는 InnoDB 엔진을 디폴트 (다른 엔진은 더 이상 지원x)
• InnoDB 엔진 키워드
  • Clustered Index, Redo - Undo, Buffer pool

캐시

MySQL에는 5버전 까지 쿼리 캐시가 존재했다. 쿼리를 실행해서 나온 데이터를 저장하는 캐시이다.
쿼리캐시를 사용하면 빠른 조회가 가능하지만 갱신시 캐시의 내용도 갱신해주어야 하고 락문제가 발생하기도했다. 그래서 8버전에 들어오면서 폐기 되었다.

소프트 파싱: SQL, 실행계획을 캐시에서 찾아 옵티마이저 과정을 생략하고 실행 단계로 넘어감(Oracle에는 존재함)
하드 파싱: SQL, 실행계획을 캐시에서 찾지못해 옵티마이저 과정을 거치고나서 실행단계로 넘어감