MySQL 아키텍쳐

 

본 내용은 real MySQL 책을 참조하여 쓰여졌습니다!

 

1. 기본 아키텍쳐

 

 

크게 MySQL 엔진과 스토리지 엔진으로 구분할 수 있습니다.

 

MySQL 엔진:

 

1)    커넥션 핸들러: 클라이언트의 접속 및 쿼리 요청을 처리

2)    SQL 파서: 클라이언트가 요청한 쿼리를 MySQL이 인식할 수 있는 단위 (토큰)로 분리해 트리형태 구조로 파싱

3)    전처리기: 파서 트리 내 토큰과 개체(컬럼명, 내장함수, 객체 접근권한)를 비교해 쿼리 문장의 구조적 오류 확인.

4)    옵티마이저: 쿼리의 최적화된 실행방법을 탐색. 클라이언트가 요청한 쿼리에 대해 최적(최저비용)의 처리경로(방법)을 결정하는 DBMS 내부의 핵심엔진

 

 

스토리지 엔진(=핸들러)

 

- 실제 데이터를 디스크 스토리지에 저장하거나 디스크 스토리지로부터 읽어오는 방법을 처리

 

2.  InnoDB 스토리지 아키텍쳐

 

 

1)    모든 테이블은 클러스터링 인덱스로 저장됩니다.

2)    모든 세컨더리 인덱스는 레코드의 주소 대신 프라이머리 키의 값을 논리적인 주소로 사용합니다.

 

-  MVCC (Multi Version Concurrency Control)

 

특징: InnoDB에선 하나의 레코드에 대해 여러 개의 버전이 동시에 관리됩니다.

목적: 잠금을 사용하지 않는 일관된 읽기를 제공하고자 합니다.

-> InnoDB의 경우 Undo Log를 통해 제공합니다.

 

이는 트랜잭션 격리 수준에 따라 동작이 달라짐을 의미하는데 다음과 같은 구조를 가집니다.

 

 

READ_UNCOMMITTED라면 버퍼 풀의 데이터를 읽어서 반환하며, 커밋 여부와 관계없이 변경된 데이터를 읽어 반환합니다.

그 이상의 격리 수준인, REPEATABLE_READ, SERIALIZABLE라면 변경되기 이전의 Undo 로그 영역의 데이터를 반환하게 됩니다.

 

이를 통해 잠금 없는 일관된 읽기를 제공할 수 있습니다.

그래서 InnoDB의 읽기 작업은 다른 트랜잭션이 가지고 있는 잠금을 기다리지 않고 읽기 작업이 가능합니다. 즉 격리 수준이 SERIALIZABLE보다 아래인 격리 수준인 경우 INSERT와 연결되지 않은 순수한 읽기 작업은 다른 트랜잭션의 변경 작업과 관계없이 항상 잠금을 대기하지 않고 바로 실행됩니다.

 

InnoDB에는 자동 데드락 감지 시스템이 있지만 구글처럼 정말 많은 트랜잭션을 실행하는 서비스의 경우 데드락 감지 스레드가 상당히 성능을 저하시키는 경우도 있어 끌 수 있는 옵션도 존재합니다. 그럴 경우 lock wait timeout를 낮춰서 사용하는 것을 추천드립니다.