[Real MySQL 8.0] 4장 아키텍처 (1) (2일차)

4장 아키텍처

MySQL 서버는 Mysql 엔진과 스토리지 엔진으로 구별할 수 있다.

4.1 MySQL 엔진 아키텍처

• MySQL 엔진의 쿼리 실행기에서 데이터를 쓰거나 읽어야 할 때는 각 스토리지 엔진에 쓰기 또는 읽기를 요청하는데, 이러한 요청을 핸들러 요청이라 한다
• MySQL 은 스레드 기반으로 동작
• 포그라운드 스레드
  • MySQL 서버에 접속된 클라이언트의 수 만큼 존재한다
  • 클라이언트가 요청하는 쿼리 문장을 처리한다
  • 커넥션을 종료하면 스레드는 스레드 캐시로 되돌아간다
  • 데이터를 데이터 버퍼나 캐시로부터 가져오며, 디스크의 데이터나 인덱스 파일로부터 데이터를 읽어와 작업을 처리한다
• 백그라운드 스레드
  • 로그를 디스크로 기록하는 스레드
  • 버퍼의 데이터를 디스크로 내려쓰는 작업을 처리하는 쓰기 쓰레드
  • 쓰기 작업을 버퍼링해서 일괄 처리하는 기능이 탑재
  • INSERT, UPDATE, DELETE 쿼리로 데이터가 변경되는 경우 데이터가 디스크의 데이터 파일로 완전히 저장될 때까지 기다리지 않아도 된다
• 글로벌 메모리 영역 vs 로컬 메모리 영역
  • 글로벌 메모리 영역
    • 클라이언트 수와 무관하게 하나의 메모리 공간
    • 테이블 캐시, 버퍼 풀 ...
  • 로컬 메모리 영역 (세션 메모리 영역)
    • 클라이언트 스레드가 쿼리를 처리하는 데 사용하는 메모리 영역
    • 커넥션 버퍼, 정렬 버퍼 ...
    • 클라이언트 스레드별로 독립저긍로 할당
• 플러그인 모델
• 컴포넌트
• 쿼리 실행 구조
  • 쿼리 파서
    • 사용자 요청으로 들어온 쿼리 문장을 토큰으로 분리해 트리 형태의 구조로 만들어낸다
  • 전처리기
    • 파서 과정으로 만들어진 트리에 구조적 문제점을 파악한다
    • 객체의 존재 여부와 접근 권한 등을 확인
  • 옵티마이저
    • 가장 저렴한 비용으로 처리할지 결정하는 역할
  • 실행 엔진
    • 만들어진 계획대로 각 핸들어에게 요청해 받은 결과를 다른 핸들러의 요청으로 연결하는 역할
  • 핸들러(스토리지 엔진)
    • 가장 밑단에서 실행 엔진의 요청에 따라 디스크로 저장하고 읽어오는 역할
• 복제
• 캐시
  • SQL 실행 결과를 메모리에 캐시
  • 테이블 변경 시 캐시 결과 삭제 -> 성능 저하
  • 쿼리 캐시는 완전히 삭제!
• 스레드 풀
  • 많다고 좋은 것이 아니다 -> 컨텍스트 스위치 비용만 증가