- 01
Schema와 current rows를 구분합니다.
- 02
Primary key와 foreign key가 write를 판정하는 과정을 직접 조작합니다.
- 03
SQL result와 transaction으로 이어지는 여섯 lesson의 순서를 확인합니다.
Database FoundationsMySQL 8.4.10
데이터베이스 개념과 실제 실행을 한 경로로 배웁니다
처음이라면 table, row, key부터 시작하고, 기본을 안다면 실제 MySQL 실행에서 index, join, version, lock과 wait를 추적하세요.
데이터베이스가 처음이라면
Database Foundations로 시작하세요
특정 engine의 내부 동작을 보기 전에 schema, current rows, key와 constraint가 무엇을 뜻하는지 같은 customers/orders 데이터로 익힙니다.
FOUNDATION 01 · 지금 학습 가능
Learning path
8개 Lab을 세 단계로 연결해 배웁니다
access와 filter에서 시작해 물리 작업, row version, lock과 wait까지 이어집니다. 각 Lab은 필요한 선수 지식과 이번에 답할 질문을 먼저 보여줍니다.
STAGE 01
Query path 읽기
SQL clause가 access, filter, join, sort, result row로 이어지는 기본 경로를 만듭니다.
- LAB 01 Lab 열기
Order Search Execution
같은 SQL은 full scan과 composite index에서 어떤 row path를 만들까요?
선수 지식 기본 SELECT · JOIN · WHERE · ORDER BY · LIMIT추적할 범위
같은 주문 조회가 full scan과 composite index에서 만드는 table, index, filter, join, sort, result 흐름을 비교합니다.
- LAB 02 Lab 열기
Composite Index Anatomy
index column order는 equality prefix, first range, ICP와 base-row lookup을 어떻게 바꿀까요?
선수 지식 LAB 01 · access path, filter, sort추적할 범위
세 가지 index order를 바꾸며 equality prefix, first range, ICP, base-row lookup, index-only projection을 실제 plan과 row로 추적합니다.
- LAB 03 Lab 열기
Cardinality & Histograms
같은 result row를 반환해도 estimate가 달라지면 왜 optimizer 판단이 달라질까요?
선수 지식 LAB 01 · rows, filtered, filesort추적할 범위
동일한 데이터에서 histogram 없음, fresh, stale 상태가 filtered와 예상 Filter row 수를 어떻게 바꾸는지 실제 bucket, plan, 128행 결과로 비교합니다.
STAGE 02
Operator와 물리 작업 추적
join algorithm, internal temporary work, secondary-to-clustered lookup을 실제 row와 page로 연결합니다.
- LAB 04 Lab 열기
Nested Loop vs Hash Join
Hash Join의 build/probe와 Nested Loop의 outer/inner lookup은 row를 어떤 순서로 만날까요?
선수 지식 LAB 01 · join row flow추적할 범위
동일한 SQL과 fixture에서 Hash Join의 build/probe와 Indexed Nested Loop의 outer/inner lookup을 native plan, 실제 rows·loops, 정확한 matched pair로 비교합니다.
- LAB 05 Lab 열기
Internal Temporary Work
GROUP BY result는 temporary rows, filesort, memory 또는 disk profile을 거쳐 어떻게 100행이 될까요?
선수 지식 LAB 03 · GROUP BY, sort, LIMIT추적할 범위
같은 GROUP BY query가 RAM, mmap overflow, InnoDB on-disk profile에서 만드는 internal temporary rows, filesort, LIMIT 경계를 exact rows와 captured memory로 추적합니다.
- LAB 06 Lab 열기
Secondary Index & Buffer Pool
secondary entry의 primary key는 어느 clustered row와 Buffer Pool page로 이어질까요?
선수 지식 LAB 02 · secondary index, base-row lookup추적할 범위
하나의 non-covering range query가 secondary entry에서 primary key를 전달해 clustered row를 찾고, cold/warm Buffer Pool page와 counter가 어떻게 달라지는지 실제 capture로 추적합니다.
STAGE 03
Version과 wait 추적
transaction snapshot, row version, record/gap lock, wait와 COMMIT의 순서를 연결합니다.
- LAB 07 Lab 열기
MVCC Consistent Read
같은 SELECT는 isolation level과 COMMIT 시점에 따라 어느 row version을 읽을까요?
선수 지식 LAB 06 · clustered row · transaction 기본추적할 범위
같은 secondary-index SELECT가 writer COMMIT 전후 REPEATABLE READ와 READ COMMITTED에서 어떤 row version을 읽는지 transaction, undo traversal Model, 실제 result로 비교합니다.
- LAB 08 Lab 열기
Locking Read: FOR UPDATE와 Next-Key Lock
FOR UPDATE range는 어느 record/gap을 잠그고, 누가 기다리며, COMMIT 뒤 무엇이 재개될까요?
선수 지식 LAB 07 · snapshot, COMMIT, row version추적할 범위
Session A의 SELECT가 Session B INSERT와 Session C UPDATE를 기다리게 만드는지 비교합니다. 같은 WHERE 절에서 plain SELECT, REPEATABLE READ + FOR UPDATE, READ COMMITTED + FOR UPDATE가 어떻게 달라지는지 봅니다.
같은 SQL이 full scan과 composite index에서 어떻게 다른 access path를 만드는지 실제 row와 함께 비교합니다.
Workbench
네 개 surface가 같은 실행 단계를 가리킵니다
- SQL
현재 실행 중인 clause와 predicate
- Execution Plan
활성 operator, access type, selected key, rows와 cost
- Data Lens
table scan, index candidate, filter, join, sort와 result row
- Plan & Evidence
raw plan line과 metric이 나온 근거
Evidence methodology
실행 evidence와 설명 Model을 분리합니다
화면에 보이는 정보는 출처에 따라 세 가지로 구분합니다.
- Captured
- MySQL 8.4.10의 EXPLAIN, Performance Schema, Handler counter와 result
- Derived · fixture
- 같은 predicate를 고정 fixture에 적용해 계산한 정확한 row 집합
- Logical model
- 인덱스 정의와 candidate key로 구성한 B-tree 설명 모델