쿼리 캐시
동일 SQL 쿼리가 실행되면 테이블을 읽지 않고 캐시 데이터를 반환한다. 하지만 테이블의 데이터가 변경되면 캐시에 저장된 데이터 중 변경 사항과 관련된 것들을 모두 삭제해야한다. 이는 심각학 동시 처리 성능 저하를 유발한다. 결국 MySQL 8.0에서부터 쿼리 캐시 기능은 완전히 제거 되었다.
쿼리 파서
쿼리 문장을 토큰으로 분리해 트리 형태의 구조로 만든다. 쿼리 문장의 기본 문법 오류를 발견하고 오류 메시지를 전달한다.
전처리기
파싱된 쿼리 문장에서 구조적인 문제점을 확인한다. 각 토큰을 테이블 이름이나 칼럼 이름, 내장 함수와 같은 객체를 매핑한다. 해당 객체의 존재 여부와 객체의 접근 권한 등을 확인한다. 실제 존재하지 않거나 권한상 사용할 수 없는 경우 오류가 발생한다.
옵티마이저
쿼리 문장을 저렴한 비용으로 가장 빠르게 처리할지를 결정한다. 실행 계획을 수립한다. DBMS의 두뇌 역할을 한다.
실행 엔진
실행 계획대로 핸들러 API를 호출한다. 핸들러 API 호출을 통해 스토리지 엔진에게 작업을 요청한다. 스토리지 엔진은 핸들러 API의 요청대로 데이터를 읽거나 쓴다. 즉, 실행 엔진은 만들어진 계획대로 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 역할을 수행한다.
GROUP BY 예
- 실행 엔진이 핸들러에게 임시 테이블을 만들라고 요청
- 다시 실행 엔진은 WHERE 절에 일치하는 레코드를 읽어오라고 핸들러에게 요청
- 읽어온 레코드들은 1번에서 준비한 임시 테이블로 저장하라고 다시 핸들러에게 요청
- 데이터가 준비된 임시 테이블에서 필요한 방식으로 데이터를 읽어오라고 핸들러에게 다시 요청
- 최종적으로 실행 엔진은 결과를 사용자나 다른 모듈로 넘김
핸들러(스토리지 엔진)
실행 엔진의 요청에 따라 데이터를 저장하고 읽어 오는 역할을 담당한다. 핸들러는 결국 스토리지 엔진을 의미한다.
'Database' 카테고리의 다른 글
| [MySQL] InnoDB 스토리지 엔진 아키텍처 - 3 (0) | 2023.02.08 |
|---|---|
| [MySQL] InnoDB 스토리지 엔진 아키텍처 - 2 (2) | 2023.02.01 |
| [MySQL] InnoDB 스토리지 엔진 아키텍처 - 1 (0) | 2023.01.11 |
| [MySQL] MySQL 아키텍처 (0) | 2023.01.06 |
| [DB] SQL JOIN (0) | 2023.01.06 |
