프로그래밍 API(우리는 현재 JAVA)에서 SQL문을 이용하여 요청을 했을 때, MySQL에서는 어떤 과정으로 요청을 처리하는지 간단하게 알아보자.
선정 이유
database라는게 정말 추상적인 것이라고 생각이 들었다.
마냥 select, create 같은 명령어는 자주 사용해봤지만, 실제 database에서는 어떻게 처리되고 어떤 구조로 되어있는지도 모르고 사용해왔다는 것을 이 책을 보면서 깨달았다.
그래서 팀원들과 대강 훑어보기 위해서 주제를 선정했다.
해당 텍스트
프로그래밍 API -> {커넥션 핸들러 -> 파서 -> 전처리기 -> 옵티마이저 -> 실행 엔진}(MySQL 엔진) -> 핸들러(스토리지 엔진)
프로그래밍 API(우리는 현재 JAVA)에서 SQL문을 이용하여 요청을 했을 때, 커넥션 핸들러에서 해당 요청을 받는다.
파서는 MySQL이 인식할 수 있는 최소 단위로 쿼리문을 분리하여, 트리 형태의 구조로 만든다.
전처리기에선 파서에서 만들어진 트리를 기반으로 쿼리 문장에 구조적인 문제점이 있는지 파악한다.
옵티마이저에서는 사용자의 요청으로 들어온 쿼리 문장을 가장 저렴한 비용으로 가장 빠르게 처리하는 성능 최적화를 결정하는 역할을 담당한다.
실행 엔진은 만들어진 계획대로 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 역할을 수행한다.
핸들러(스토리지 엔진)는 실행 엔진의 요청에 따라 데이터를 디스크로 저장하고 디스크로부터 읽어오는 역할을 담당한다.
주제
프로그래밍 API(우리는 현재 JAVA)에서 SQL문을 이용하여 요청을 했을 때, MySQL에서는 어떤 과정으로 요청을 처리하는지 간단하게 알아보자.
선정 이유
database라는게 정말 추상적인 것이라고 생각이 들었다. 마냥 select, create 같은 명령어는 자주 사용해봤지만, 실제 database에서는 어떻게 처리되고 어떤 구조로 되어있는지도 모르고 사용해왔다는 것을 이 책을 보면서 깨달았다. 그래서 팀원들과 대강 훑어보기 위해서 주제를 선정했다.
해당 텍스트
프로그래밍 API -> {커넥션 핸들러 -> 파서 -> 전처리기 -> 옵티마이저 -> 실행 엔진}(MySQL 엔진) -> 핸들러(스토리지 엔진) 프로그래밍 API(우리는 현재 JAVA)에서 SQL문을 이용하여 요청을 했을 때, 커넥션 핸들러에서 해당 요청을 받는다.
파서는 MySQL이 인식할 수 있는 최소 단위로 쿼리문을 분리하여, 트리 형태의 구조로 만든다.
전처리기에선 파서에서 만들어진 트리를 기반으로 쿼리 문장에 구조적인 문제점이 있는지 파악한다.
옵티마이저에서는 사용자의 요청으로 들어온 쿼리 문장을 가장 저렴한 비용으로 가장 빠르게 처리하는 성능 최적화를 결정하는 역할을 담당한다.
실행 엔진은 만들어진 계획대로 각 핸들러에게 요청해서 받은 결과를 또 다른 핸들러 요청의 입력으로 연결하는 역할을 수행한다.
핸들러(스토리지 엔진)는 실행 엔진의 요청에 따라 데이터를 디스크로 저장하고 디스크로부터 읽어오는 역할을 담당한다.
관련 페이지
77P-78P, 91P-92P