Ch04 아키텍처

한 줄 정의

MySQL 서버는 SQL을 처리하는 MySQL 엔진(두뇌)과 실제 데이터를 읽고 쓰는 스토리지 엔진(손발)으로 나뉘며, 이 구조를 이해해야 쿼리 튜닝의 근거를 잡을 수 있습니다.

쉽게 말하면

레스토랑에 비유하면 MySQL 엔진은 주문을 받고 요리 순서를 결정하는 셰프(옵티마이저) 이고, 스토리지 엔진은 실제로 재료를 꺼내오고 보관하는 창고 관리자 입니다.

셰프가 아무리 뛰어나도 창고가 비효율적이면 요리가 느려지고, 반대로 창고가 완벽해도 셰프의 판단이 잘못되면 불필요한 재료를 가져오게 됩니다.

왜 중요한가?

MySQL의 성능 문제 대부분은 이 아키텍처에 대한 이해 부족에서 시작됩니다.

“인덱스를 탔는데 왜 느린가?” → MySQL 엔진과 스토리지 엔진의 역할 분담을 모르면 답할 수 없습니다
“서버 메모리를 늘렸는데 왜 빨라지지 않는가?” → 버퍼 풀과 리두 로그의 관계를 모르면 원인을 찾을 수 없습니다
“트랜잭션이 길면 왜 전체 성능이 떨어지는가?” → MVCC와 언두 로그의 동작을 모르면 설명할 수 없습니다

핵심 내용

이 챕터는 4개의 큰 주제로 구성됩니다.

4.1 MySQL 엔진 아키텍처

서브노트	핵심 주제
Ch04-1 MySQL 엔진 아키텍처	스레딩 구조, 메모리 할당, 쿼리 실행 파이프라인, 스레드 풀, 트랜잭션 지원 메타데이터

flowchart LR
    Client[클라이언트] --> Handler[커넥션 핸들러]
    Handler --> Parser[쿼리 파서]
    Parser --> Preprocessor[전처리기]
    Preprocessor --> Optimizer[옵티마이저]
    Optimizer --> Executor[실행 엔진]
    Executor --> Storage[스토리지 엔진<br/>InnoDB / MyISAM]
    Storage --> Disk[(디스크)]

4.2 InnoDB 스토리지 엔진 아키텍처

서브노트	핵심 주제
Ch04-2 InnoDB 스토리지 엔진	PK 클러스터링, MVCC, 버퍼 풀, 언두/리두 로그, 어댑티브 해시 인덱스

이 챕터에서 가장 방대하고 중요한 섹션 입니다. InnoDB가 MySQL 8.0의 사실상 유일한 스토리지 엔진이기 때문입니다.

4.3 MyISAM 스토리지 엔진 아키텍처

서브노트	핵심 주제
Ch04-3 MyISAM 스토리지 엔진	키 캐시, 클러스터링 없는 구조, ROWID 기반

MySQL 8.0에서 MyISAM은 사실상 퇴출 수순입니다. InnoDB와의 구조적 차이를 이해하는 용도로 가치가 있습니다.

4.4 MySQL 로그 파일

서브노트	핵심 주제
Ch04-4 MySQL 로그 파일	에러 로그, 제너럴 쿼리 로그, 슬로우 쿼리 로그, pt-query-digest

정리

InnoDB vs MyISAM 핵심 차이

기준	InnoDB	MyISAM
잠금 단위	레코드 수준	테이블 수준
트랜잭션	지원	미지원
PK 클러스터링	있음 (PK 순서로 디스크 저장)	없음 (INSERT 순서로 저장)
세컨더리 인덱스 포인터	PK 값 (논리적 주소)	ROWID (물리적 주소)
데이터 캐시	자체 버퍼 풀	OS 캐시에 의존
인덱스 캐시	자체 버퍼 풀	키 캐시 (인덱스만)
외래 키	지원	미지원
MVCC	지원	미지원
MySQL 8.0 위상	기본 + 유일한 실질 엔진	사실상 퇴출

내 생각

MySQL 서버 구조에서 가장 핵심적인 인사이트는 “쿼리 처리의 대부분은 MySQL 엔진이 하고, 스토리지 엔진은 데이터 읽기/쓰기만 담당한다” 는 것입니다. GROUP BY, ORDER BY 같은 복잡한 처리는 스토리지 엔진이 아니라 MySQL 엔진의 쿼리 실행기에서 처리됩니다.
MySQL 8.0에서 MyISAM/MEMORY를 쓸 이유는 없습니다. 시스템 테이블까지 전부 InnoDB로 전환됐고, 전문 검색/공간 인덱스도 InnoDB가 지원합니다.

출처

Real MySQL 8.0 (1권), Ch04 아키텍처

Dev Wiki

탐색기