DEV 2026.05.02 · 14 min
Intermediate Database Internals · 1
InnoDB는 왜 데이터를 Page 단위로 읽고 쓰는가
16KB Page부터 WAL까지, InnoDB의 모든 물리 저장 결정이 하나의 원칙 — I/O 비용 최소화 — 에서 비롯됨을 추적한다.
총 7편 · 순서대로 읽기를 권장
16KB Page부터 WAL까지, InnoDB의 모든 물리 저장 결정이 하나의 원칙 — I/O 비용 최소화 — 에서 비롯됨을 추적한다.
Binary Search Tree의 한계부터 Covering Index, Composite Index 순서 설계, 인덱스를 무력화하는 쿼리 패턴까지, B+Tree가 만들어내는 모든 설계 결정을 추적한다.
Parse Tree부터 Handler_read_* 변수까지, MySQL 쿼리 실행의 다섯 단계와 Cost-Based Optimizer의 판단 근거, 그리고 그 판단이 틀리는 이유를 추적한다.
Undo Log부터 Gap Lock까지, InnoDB가 ACID 네 글자를 각각 다른 메커니즘으로 구현하는 방식과 그 상호작용을 추적한다.
S/X Lock의 호환 행렬부터 Gap Lock Deadlock, 데드락 로그 분석, Optimistic vs Pessimistic 선택까지 — InnoDB Lock 설계의 일관된 원리를 추적한다.
Slow Query 분석부터 N+1 탐지, 페이징 함정, 파티셔닝 설계, Connection Pool 튜닝까지 — DB 성능 저하의 다섯 가지 뿌리를 하나의 흐름으로 추적한다.
Binary Log 3단계 복제 구조부터 GTID 기반 자동 페일오버, Spring AbstractRoutingDataSource 구현까지 — 비동기 복제의 구조적 특성과 그 대가를 추적한다.