01 / 21
Real MySQL 8.0 · 발표자 2

SQL 한 문장이 InnoDB 페이지를 만날 때까지

서버 경계, 연결과 메모리, 쿼리 처리, 저장 구조를 하나의 요청 흐름으로 연결합니다.

MySQL / InnoDB Architecture2026.08.14Real MySQL 8.0
SELECT * FROM orders WHERE id = 42;
Connectionclient · session · request thread
SQL Layerparse · resolve · optimize · execute
Handler APIstorage engine boundary
InnoDB Pagebuffer pool · tablespace · clustered index
02 / 21
LEARNING MAP · 한 쿼리의 네 구간

오늘 따라갈 네 개의 경계

01

연결

Client 요청이 Connection을 만들고 Session 상태와 실행 단위를 얻습니다.

02

SQL 처리

Parser, Resolver/Preparation, Optimizer, Executor가 문장을 계획으로 바꿉니다.

03

엔진 경계

Executor가 Handler API를 통해 InnoDB에 행과 인덱스 접근을 요청합니다.

04

저장 구조

Buffer Pool, Tablespace, Page, Clustered Index가 실제 I/O를 결정합니다.

03 / 21
SYSTEM BOUNDARY · MySQL ≠ InnoDB

MySQL 서버와 InnoDB의 역할 경계

공통 SQL 계층과 물리 저장 계층은 분리됩니다.

실행 계획은 서버가 만들고, 실제 레코드·인덱스·페이지 접근은 스토리지 엔진이 수행합니다.

Client / ConnectorSQL 요청, 결과 수신outside server
MySQL ServerConnection · SQL parsing · optimization · executioncommon layer
Storage Engine API테이블·인덱스·행 접근 인터페이스handler boundary
InnoDB트랜잭션 · 행 잠금 · Buffer Pool · Tablespacedefault engine
Source: MySQL 8.0 Reference Manual · Overview of MySQL Storage Engine Architecture / Introduction to InnoDB
04 / 21
PLUGGABLE STORAGE · 공통 인터페이스 아래 다른 구현

Plugin Storage Engine 구조

Factual basis: MySQL 8.0 Reference Manual · Pluggable Storage Engine Architecture / InnoDB, MyISAM, MEMORY
05 / 21
CONNECTION LIFECYCLE · 비슷해 보여도 같은 개념은 아님

Client → Connection → Session → Thread

Client

애플리케이션이나 CLI가 Connector로 접속을 시도합니다.

TCP/IP · Unix socket

Connection

인증된 통신 채널입니다. 요청과 결과가 이 채널을 오갑니다.

connection_id

Session

세션 변수, 문자 집합, 트랜잭션 상태 같은 논리 문맥입니다.

@@session.*

Thread

기본 모델에서 연결 요청을 처리하는 실행 단위입니다.

one-thread-per-connection
예외: Thread Pool을 쓰면 하나의 세션이 평생 하나의 OS 스레드에 고정된다고 볼 수 없습니다. 연결과 스레드를 동의어로 보지 마세요.
Source: MySQL 8.0 Reference Manual · Connection Management / Performance Schema threads table
06 / 21
MEMORY LIFETIME · 공유·세션·작업별 할당을 분리

Global Memory vs Session Memory

Global / Shared

Buffer Pool

여러 연결이 함께 쓰는 InnoDB 페이지 캐시입니다. 테이블 캐시와 Performance Schema 메모리도 서버 범위에서 관리됩니다.

Session baselinethread stack, network/result buffer, session state
Statement / operationsort, join, read buffer는 필요한 작업이 생길 때 할당
중요한 오해global + max_connections × 모든 최대 버퍼는 실제 할당 모델이 아닙니다.
Source: MySQL 8.0 Reference Manual · How MySQL Uses Memory / ORDER BY Optimization
07 / 21
QUERY PIPELINE · SQL 문자열이 실행 결과가 되는 과정

SQL Query 처리 흐름

01

Parser

문법을 확인하고 SQL을 내부 트리로 만듭니다.

02

Resolver / Preparation

테이블·열·권한·의미를 해석합니다. 흔히 Preprocessor로 묶어 설명합니다.

03

Optimizer

통계와 비용으로 접근 방법과 조인 순서를 선택합니다.

04

Executor

계획을 순회하고 Handler API로 엔진에 행을 요청합니다.

05

Storage Engine

인덱스·레코드·페이지를 읽거나 바꾸고 결과를 돌려줍니다.

Source: MySQL 8.0.46 Source Code Documentation · SQL Query Execution / Query Resolver / Query Optimizer
08 / 21
UNDERSTAND · 문법과 의미는 다른 관문

Parser와 Resolver/Preparation

Parser

SELECT * FORM orders;
▲ syntax error
  • 토큰과 문법 규칙 확인
  • SQL을 내부 트리로 구성
  • 옵티마이저 힌트 인식

Resolver / Preparation

SELECT ghost_col FROM orders;
▲ unknown column
  • 테이블·열·별칭·뷰 참조 해석
  • 권한과 의미 조건 확인
  • 교육 자료의 Preprocessor 범주에 해당
Boundary note: MySQL 공식 구현은 “Preprocessor”를 하나의 고정 독립 컴포넌트로 보장하지 않습니다.
09 / 21
OPTIMIZER · 인덱스 하나가 아니라 계획 전체를 선택

Optimizer가 고르는 실행 계획

SELECT o.id, c.name
FROM orders o
JOIN customers c
  ON c.id = o.customer_id
WHERE o.status = 'PAID';

Full scan

orders 전체를 읽고 조건을 적용합니다.

  • 선택도가 낮은 조건
  • 테이블 통계와 예상 행 수
estimated cost: high

Index + join

status 인덱스로 후보를 줄이고 PK로 customers를 찾습니다.

  • 사용 가능한 인덱스
  • 조인 순서와 랜덤 I/O
estimated cost: lowest

Hash join

조건과 버전에 따라 해시 기반 조인도 후보가 됩니다.

  • 조인 입력의 예상 크기
  • 메모리와 빌드 비용
estimated cost: medium
Use: EXPLAIN은 예상 계획, EXPLAIN ANALYZE는 실제 실행과 iterator별 측정치를 보여줍니다.
10 / 21
EXECUTION BOUNDARY · 계획 제어와 데이터 접근을 분리

Executor와 Storage Engine의 핸드셰이크

Executor

  • 실행 계획의 iterator를 순회
  • WHERE·JOIN·정렬·집계 흐름 제어
  • 필요한 행 연산을 Handler에 요청
Handler
API

InnoDB

  • 인덱스 탐색과 레코드 읽기
  • Buffer Pool에서 페이지 확인
  • 필요하면 Tablespace I/O 수행
Key boundary: 실행기는 파일을 직접 읽지 않고 스토리지 엔진 인터페이스로 행 연산을 요청합니다.
11 / 21
INNODB · 메모리와 디스크 구조를 함께 운영

InnoDB Architecture

In-Memory

Buffer Pool, Change Buffer, Log Buffer가 데이터와 변경을 다룹니다. Adaptive Hash Index는 반복되는 B-tree 접근을 관찰해 hot path에 hash lookup을 보조하며 효과는 workload에 따라 달라집니다.

On-Disk

Tablespace, Redo Log, Doublewrite 파일 등이 데이터 영속성과 복구를 받칩니다.

Source: MySQL 8.0 Reference Manual, Figure 17.1 “InnoDB Architecture”, © Oracle
12 / 21
BUFFER POOL · 결과 캐시가 아니라 페이지 캐시

Buffer Pool에서 읽고 쓰기

1

Page lookup

필요한 데이터·인덱스 페이지가 Buffer Pool에 있는지 확인합니다.

2

Miss → read

없으면 Tablespace에서 페이지를 읽어 캐시에 올립니다.

3

Dirty page

수정된 페이지는 메모리에 남고 백그라운드에서 디스크로 flush됩니다.

4

LRU variant

midpoint insertion으로 큰 스캔이 자주 쓰는 페이지를 모두 밀어내지 않도록 조절합니다.

Source: MySQL 8.0 Reference Manual · Buffer Pool, Figure 17.2, © Oracle
13 / 21
TABLESPACE · 파일과 논리 저장 공간을 구분

Tablespace 지형도

Tablespace = pages를 담는 논리 공간

orders.ibd
data + indexes

file-per-table은 한 테이블의 데이터와 인덱스를 하나의 .ibd 테이블스페이스 파일에 둡니다.

System

공유 내부 구조·시스템 데이터

File-per-table

테이블별 독립 .ibd, MySQL 8.0 기본 배치

General

여러 테이블을 담는 사용자 생성 공유 공간

Undo

최근 변경을 되돌리는 undo log 저장

Temporary

세션·글로벌 임시 데이터 저장

주의

Tablespace와 OS 파일은 항상 1:1이 아닙니다.

Source: MySQL 8.0 Reference Manual · InnoDB Tablespaces / File-Per-Table / General / Undo Tablespaces
14 / 21
STORAGE UNITS · 기본값과 고정값을 구분

Page → Extent → Segment

Page디스크 I/O와 Buffer Pool 캐시의 기본 단위. 기본값 16KB.
Extent16KB 페이지 64개가 모인 1MB 연속 공간.
SegmentExtent 묶음 · B-tree의 leaf와 non-leaf 공간을 목적별로 소유하는 논리 단위.
주의innodb_page_size는 인스턴스 초기화 때 4–64KB 범위에서 선택할 수 있습니다.
Source: MySQL 8.0 Reference Manual · File Space Management; MySQL InnoDB Engineering Blog, © Oracle
15 / 21
CLUSTERED INDEX · 리프 레코드가 행 자체를 담음

Primary Key Clustering · Foreign Key

PK 1…500 | 501…999
PK 1…500
PK 501…999
PK 42full row data
PK 777full row data
RULE 1

PRIMARY KEY

명시한 PK를 clustered index로 사용합니다.

RULE 2

UNIQUE NOT NULL

PK가 없으면 조건을 만족하는 첫 unique index를 사용합니다.

RULE 3

GEN_CLUST_INDEX

둘 다 없으면 6-byte 숨은 row ID 기반 인덱스를 만듭니다.

4.2.2 Foreign Key: InnoDB가 부모·자식 참조 무결성과 cascade 동작을 검사합니다. foreign_key_checks=0 뒤 다시 켜도 기존 행을 소급 검증하지는 않습니다.
주의: clustered layout은 SELECT 결과 순서를 보장하지 않습니다. 결정적 순서는 ORDER BY로 지정합니다.
16 / 21
SECONDARY INDEX · 물리 주소 대신 Primary Key를 저장

Secondary Index의 두 번째 탐색

Secondary B-tree

email = 'kim@example.com'PK = 42

보조 키와 함께 해당 행의 Primary Key 열을 저장합니다.

→

Clustered B-tree

PK = 42full row data

전체 행이 필요하면 PK로 clustered index를 다시 탐색합니다.

설계 함의: Primary Key가 길수록 모든 Secondary Index가 함께 커집니다. 다만 커버링 인덱스라면 두 번째 탐색을 생략할 수 있습니다.
Source: MySQL 8.0 Reference Manual · Clustered and Secondary Indexes
17 / 21
STORED OBJECTS · 공식 용어의 포함 관계

Stored Object 용어 지도

Stored Object

서버에 SQL 정의를 저장해 나중에 실행하거나 참조하는 객체의 상위 범주

Stored Program

실행되는 서버 객체의 묶음

Stored RoutineStored Procedure · Stored Function
TriggerEvent

View

참조할 때 결과 집합을 만드는 가상 테이블. 이번 발표의 상세 범위에서는 제외합니다.

용어 규칙: Procedure와 Function을 묶으면 Routine, 여기에 Trigger와 Event를 더하면 Program입니다.
Source: MySQL 8.0 Reference Manual · Chapter 27 Stored Objects
18 / 21
STORED PROGRAM · 호출 조건부터 구분

Procedure · Function · Trigger · Event

OBJECTSTARTS WHENRETURNS / ACTSCHECK FIRST
ProcedureCALL name(...)OUT/INOUT, result set트랜잭션 범위와 호출자가 명시적
Functionexpressionscalar value부작용·동적 SQL·binary log 제약
TriggerBEFORE / AFTER DMLFOR EACH ROW숨은 실행과 OLD/NEW 의존
Eventtime schedulescheduled SQLevent_scheduler=ON과 중복 실행
Source: MySQL 8.0 Reference Manual · Stored Objects / Trigger Syntax / Event Scheduler Configuration
19 / 21
DECISION · DB 안에서 자동 실행할 이유가 분명한가

Stored Program 선택 체크리스트

호출자가 보여야 하나?
Procedure는 CALL로 호출이 드러납니다. Trigger는 SQL 표면에 드러나지 않아 관찰·디버깅 비용이 커집니다.
식 안에서 값이 필요한가?
Function은 scalar value에 맞지만, 부작용·동적 SQL·트랜잭션·binary logging 제약을 먼저 확인합니다.
데이터 변경에 반응하나?
Trigger는 INSERT/UPDATE/DELETE의 BEFORE/AFTER에 FOR EACH ROW로 실행됩니다. SELECT는 trigger event가 아닙니다.
시간이 실행 조건인가?
Event는 event_scheduler=ON과 권한을 확인합니다. 실행 시간이 주기보다 길면 중복 실행 가능성도 설계합니다.
운영 원칙: DB 내부 자동화가 애플리케이션 코드나 외부 scheduler보다 더 명확하고 관찰 가능한지 비교합니다.
20 / 21
RECAP · 모든 개념을 한 요청으로 회수

SELECT 한 문장의 End-to-End 경로

1. Connection세션 상태와 요청 처리 단위 생성
2. SQL Layerparse → resolve → optimize → execute
3. Handler API서버와 엔진의 책임 경계
4. Buffer Pool페이지 hit/miss와 dirty page
5. Clustered IndexPK 기반 행 탐색과 결과 반환
Diagram source: bundled Archify · showcase validation 9/9, 0 errors, 0 warnings · factual basis: MySQL 8.0 official documentation
21 / 21
TAKEAWAY · 구조를 진단 습관으로

세 가지 렌즈로 MySQL을 읽는다

01 / BOUNDARY

어느 계층인가

MySQL 서버의 공통 SQL 계층과 InnoDB의 데이터 접근 책임을 먼저 나눕니다.

02 / PLAN

어떤 계획인가

옵티마이저가 선택한 접근 방법과 실행기의 실제 흐름을 EXPLAIN으로 확인합니다.

03 / PAGE

어떤 페이지인가

Buffer Pool hit/miss, Tablespace, Clustered Index가 만든 I/O 비용을 추적합니다.

ConnectionSQL LayerHandlerInnoDB Page