DEV 2026.05.02 · 12 min
Intermediate Database Internals · 2
데이터베이스 인덱스는 왜 B+Tree인가
Binary Search Tree의 한계부터 Covering Index, Composite Index 순서 설계, 인덱스를 무력화하는 쿼리 패턴까지, B+Tree가 만들어내는 모든 설계 결정을 추적한다.
총 6개의 글
Binary Search Tree의 한계부터 Covering Index, Composite Index 순서 설계, 인덱스를 무력화하는 쿼리 패턴까지, B+Tree가 만들어내는 모든 설계 결정을 추적한다.
S/X Lock의 호환 행렬부터 Gap Lock Deadlock, 데드락 로그 분석, Optimistic vs Pessimistic 선택까지 — InnoDB Lock 설계의 일관된 원리를 추적한다.
Performance Schema의 누적 통계부터 InnoDB 상태 스냅샷, sys 스키마, MySQL 8.0 히스토그램, 운영 장애 패턴까지 — 데이터 기반 진단 철학을 추적한다.
인덱스 대체라는 오해부터 프루닝 조건, 로컬 인덱스의 함정, 운영 DDL 비용까지 — MySQL 파티셔닝의 설계 결정을 추적한다.
16KB Page부터 WAL까지, InnoDB의 모든 물리 저장 결정이 하나의 원칙 — I/O 비용 최소화 — 에서 비롯됨을 추적한다.
Undo Log부터 Gap Lock까지, InnoDB가 ACID 네 글자를 각각 다른 메커니즘으로 구현하는 방식과 그 상호작용을 추적한다.