MySQL

MySQL

• 대표적인 관계형 데이터베이스
• 오픈소스

MySQL엔진

쿼리파서와 전처리기는 컴파일 과정과 매우 유사하다.

하지만 SQL은 프로그래밍 언어 처럼 컴파일 타임때 검증할 수 없어 매번 구문 평가를 진행

• 쿼리파서
  • SQL을 파싱하여 Syntax Tree를 만듬
  • 이 과정에서 문법 오류 검사가 이루어짐
• 전처리기
  • 쿼리파서에서 만든 Tree를 바탕으로 전처리 시작
  • 테이블이나 컬럼 존재 여부, 접근권한 등 Semantic 오류 검사
• 옵티마이저
  • 쿼리를 처리하기 위한 여러 방법들을 만들고, 각 방법들의 비용정보와 테이블의 통계정보를 이용해 비용을 산정
  • 테이블 순서, 불필요한 조건 제거, 통계정보를 바탕으로 전략을 결정(실행 계획 수립)
  • 옵티마이저가 어떤 전략을 결정하는냐에 따라 성능이 많이 달라진다.
  • 가끔씩 비효율적인 판단을 해 개발자가 힌트를 사용해 도움을 줄 수 있다.
• 쿼리실행기
  • 옵티마이저가 결정한 계획대로 스토리지 엔진에 요청을 한다.
  • 이 때Handler API를 사용한다.
  • 옵티마이저 -> 쿼리실행기 ->(Handler API) -> 스토리지 엔진

스토리지 엔진

• 디스크에서 데이터를 가져오거나 저장하는 역할
• MySQL 스토리지 엔진은 플러그인 형태로 Handler API만 맞춘다면 직접 구현해서 사용할 수 있다.
• InnoDB, MyIsam 등 여러개의 스토리지 엔진이 존재
• 8.0대 부터는 InnoDB엔진이 기본값

InnoDB의 핵심키워드

• Clusterd Index
• Redo-Undo
• Buffer pool

 

 

쿼리캐시

• MySQL 5.0까지는 쿼리 캐시라는 것이 있었으나 8.0대에 들어와서 폐기됨
• 중복된 요청일시 성능의 향상을 위해 캐시에서 바로 꺼내어서 주는 용도 였지만 데이터베이스의 데이터가 달라지면서 생기는 Lock 등과 같은 문제점때문에 폐기됨 (이점보다 문제점이 크다고 판단)
• 오라클에서는 소프트파싱과 하드파싱이 있다.
  캐시와는 조금 다르다. 캐시는 데이터를 캐시에서 바로 찾는 것이고(데이터를 캐시에 저장), 소프트 파싱은 옵티마이저 과정(실행계획)을 생략하는 것이다.(옵티마이저과정을 캐시에저장, 실행전략만 빠르게 세우고 데이터는 DB에서 가져온다.)
  
  • 소프트 파싱: SQL, 실행 계획을 캐시에서 찾아 옵티마이저 과정을 생략하고 실행 단계로 넘어감, 하지만 모든 SQL과 매핑해 데이터까지 캐싱하지는 않음(힌트나 설정으로 가능하긴 하다.)
  • 하드 파싱: SQL, 실행 계획을 캐시에서 찾지 못해 옵티마이저 과정을 거치고나서 실행단계로 넘어감
• 현재 MySQL에는 소프트 파싱이 없지만 쿼리캐시가 있었다.(5.0이전)
• 쿼리 캐시는 SQL에 해당하는 데이터를 저장하는 것
• 쿼리캐시는 데이터를 캐시하기때문에 테이블의 데이터가 변경되면 캐시의 데이터도 함께 갱신시켜줘야함
• MySQL의 쿼리캐시, Oracle의 소프트 파싱 모두 성능 최적화를 위해 캐시라는 기술을 도입했었다.
  하지만 이 둘은 캐시의 범위가 다르다.
• 캐시를 도입할 때는 항상 만료정책을 고려해야한다.
  쿼리캐시는 소프트 파싱에 비해 조회성능은 더 높지만(디스크까지안가니깐) 캐시데이터 관리에 더 높은 비용이 들어감