MySQL

MySQL은 크게 MySQL 엔진과 스토리지 엔진으로 나뉜다. MySQL은 사람의 머리 역할을 담당하고, 스토리지 엔진은 손발 역할을 담당하는데 이들의 구조에 대해 자세히 알아보자.MySQL의 전체 구조는 위 다이어그램과 같이 정리할 수 있다. MySQL은 C, JDB

MySQL은 프로세스 기반이 아닌 쓰레드 기반으로 작동하는데, 크게 포그라운드 쓰레드와 백그라운드 쓰레드로 구분된다. 대부분의 쓰레드가 백그라운드이고, 소수의 쓰레드가 포그라운드이다. 백그라운드 쓰레드는 MySQL 설정에 따라 바뀔 수 있으며, 동일한 이름의 쓰레드는

MySQL의 메모리 구조는 글로벌 메모리 영역과 로컬 메모리 영역(커넥션 또는 세션 메모리 영역이라고도 한다.)으로 나뉜다. 글로벌 메모리 영역은 MySQL 시작 시 OS로부터 할당되고, 로컬 메모리 영역은 클라이언트 쓰레드가 사용하는 영역이다.글로벌 메모리 영역은 M

MySQL은 플러그인 모델이라는 독특한 구조를 사용한다. 원하는 기능들을 플러그인으로 개발해 MySQL에 추가함으로써 확장이 가능하다. 전문 검색 엔진을 위한 검색어 파서, 비밀번호 검증과 커넥션 제어 등 많은 기능이 플러그인으로 구현되어 제공된다. 스토리지 엔진 또한

MySQL에서 쿼리가 실행되는 과정은 위와 같은 구조로 간략하게 표현할 수 있다.쿼리 파서는 쿼리 문장을 토큰으로 분리해 파서 트리를 생성한다. 이 과정에서 쿼리 문장의 기본 문법 오류가 발견되면 사용자에게 오류 메시지가 전달된다.파서 트리를 기반으로 쿼리에 구조적인

같은 데이터에 대해 같은 요청이 반복해서 들어오는 상황에서 같은 작업을 계속해서 실행하는 것은 비효율적일 것이다. 이로 인해 MySQL은 쿼리 캐시라는 것을 사용했다. 쿼리 캐시는 빠른 응답을 필요로 하는 환경에서 매우 중요한 역할을 담당했다. 쿼리 캐시는 SQL의 실

InnoDB는 MySQL에서 사용할 수 있는 스토리지 엔진 중 거의 유일하게 레코드 기반의 잠금을 제공해 높은 동시성 처리가 가능하고, 안정적이며 성능이 뛰어나다. InnoDB의 개략적인 구조는 아래 그림과 같다.InnoDB 스토리지 엔진의 주요 특징은 다음과 같다.I

InnoDB 버퍼 풀은 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간이다. 쓰기 작업을 버퍼링을 통해 일괄 작업으로 처리할 수 있게 함으로써 디스크의 랜덤 I/O 횟수를 줄일 수 있다. 1. 버퍼 풀의 구조 InnoDB 버퍼 풀은 메모리 공간을 페

RDBMS에서INSERT나UPDATE, DELETE와 같은 작업은 데이터 파일을 변경하는 작업 뿐만 아니라 해당 테이블의 인덱스를 갱신하는 작업도 필요하다. 만약 InnoDB 버퍼 풀에 해당 인덱스 페이지가 존재한다면 바로 갱신이 가능하지만, 그렇지 않다면 디스크 I/

InnoDB의 어댑티브 해시 인덱스는 InnoDB 스토리지 엔진에서 자주 사용하는 데이터에 대한 해시 인덱스로, 사용자가 수동으로 생성하는 인덱스가 아니라 InnoDB가 자동으로 생성하는 인덱스다. 일반적인 인덱스의 경우 B-Tree 자료구조를 사용하는데, B-Tree

리두 로그(Redo log)는 트랜잭션의 영속성을 지원하는데, 예상치 못한 문제로 인해 MySQL이 비정상적으로 종료됐을 때 데이터 파일에 기록되지 못한 데이터를 잃지 않게 해준다. MySQL은 데이터 변경 내용을 디스크에 기록하기 전에 리두 로그로 먼저 기록하는데,

MySQL에서 리두 로그는 리두 로그의 용량을 줄이기 위해 데이터 페이지의 변경 사항만 기록한다. 그렇기 때문에, 리두 로그가 존재하더라도 MySQL에서 더티 페이지를 디스크로 쓸 때 예기치 못한 오류로 인해 MySQL가 종료되어 페이지의 일부분만 기록하는 파셜 페이지

MySQL에는 동시성 제어를 위한 여러 가지 종류의 잠금이 있다. 잠금은 여러 커넥션에서 동시에 동일한 자원을 요청한 경우 순서대로 한 시점에는 하나의 커넥션만 변경할 수 있게 해주는 역할을 한다. MySQL에서 잠금은 크게 MySQL 엔진 레벨의 잠금과 스토리지 엔진