하나의 Session이 같은 SELECT를 cold-page와 warm-page capture variant에서 실행합니다.
Secondary index에서 clustered row까지
secondary index · clustered row · Buffer Poolmysql 8.4.10captured evidence
English학습 안내
이 Lab에서 답할 질문
non-covering secondary index range에서 어떤 entry가 읽히고 carried primary key가 어느 clustered row lookup으로 이어지나요?
실행 엔진: mysql 8.4.10
동일한 secondary index entries, selected primary keys, clustered rows와 반환 checksum을 사용합니다.
실행 SQL
SELECT id, customer_id, status, ordered_at, total_cents
FROM orders
WHERE customer_id = 412
AND status = 'PAID'
AND ordered_at >= '2025-01-01 00:00:00'
ORDER BY ordered_at DESC, id DESC
LIMIT 20;
variant별 captured page-state snapshot과 counter delta가 달라지며 화면의 강조 page가 바뀝니다.
secondary index → primary key → clustered row의 논리 lookup과 최종 결과 rows는 동일합니다.
index가 total_cents를 포함하지 않는다면 다음 단계는 무엇일까요?
cold variant의 carried primary key 단계를 열어 secondary entry가 어떤 primary key를 들고 있고 그것이 왜 필요한지 확인하세요.
- 어디를 보나요?
- Index/row 상세에서 carried primary key를, Buffer Pool evidence에서 page-state와 counter를 함께 봅니다.
- 이동할 화면
Cold · carried primary key
무엇이 보여야 하나요?
확인할 관찰
idx_orders_customer_status_ordered_id의 explicit id key part가 primary key를 전달하고, SELECT의 total_cents는 entry에 없으므로 그 key가 PRIMARY lookup key가 됩니다. page-state와 counter는 Captured이고 secondary entry에서 clustered row로 가는 경로는 Model입니다.
근거 경계- Captured
- cold variant의 page-state snapshot과 counter delta
- Model
- carried primary key로 clustered row를 찾는 논리 경로
Checkpoint · evidence로 설명하기cold와 warm 화면을 cache 적중 여부 또는 실제 physical I/O 순서로 설명해도 되나요?답과 근거 확인
안 됩니다. 화면은 captured page-state snapshot과 counter delta를 보여 줍니다. secondary entry에서 clustered row로 이어지는 것은 논리 model이며 실제 physical I/O 순서를 재현하지 않습니다.
근거 경계- Captured
- page-state snapshot과 counter delta
- Model
- secondary entry에서 clustered row로 이어지는 논리 경로
non-covering index는 secondary entry에서 끝나지 않습니다. carried primary key와 base-row lookup을 구분하되 page state를 I/O trace로 과장하지 않아야 합니다.
다음 Lab에서는 같은 clustered row가 transaction snapshot에 따라 어느 row version으로 보이는지 MVCC 관점에서 이어서 봅니다.
용어 확인
base-row lookup처음 다루는 Lab 06- secondary index entry에 없는 column을 얻기 위해 carried primary key로 clustered record를 찾는 논리 단계입니다.
Buffer Pool처음 다루는 Lab 06- InnoDB가 index와 data page를 memory에 보관하고 재사용하는 cache 영역입니다.
B-tree처음 다루는 Lab 02- 정렬된 key를 계층적으로 보관해 equality와 range 탐색을 지원하는 index 구조입니다.
01 · SOURCE
Exact SQL
SELECT id, customer_id, status, ordered_at, total_cents
FROM orders
WHERE customer_id = 412
AND status = 'PAID'
AND ordered_at >= '2025-01-01 00:00:00'
ORDER BY ordered_at DESC, id DESC
LIMIT 20;- Limit
LIMIT 20 - range scan
secondary index
02 · FLOW
01 / 17Native plan과 actual iterator
limitTREE line 1
-> Limit: 20 row(s) (cost=14.2 rows=20)
index-range-scanTREE line 2
-> Index range scan on orders using idx_orders_customer_status_ordered_id over (customer_id = 412 AND status = 'PAID' AND ordered_at <= '2025-01-01 00:00:00'), with index condition: ((orders.`status` = 'PAID') and (orders.customer_id = 412) and (orders.ordered_at >= TIMESTAMP'2025-01-01 00:00:00')) (cost=14.2 rows=31)
DATA PATH
ModelIndex entry에서 clustered row까지
WHERE range
Derived · fixtureMatching secondary entries
| customer_id | status | ordered_at | id · primary key |
|---|---|---|---|
| 412 | PAID | 2026-06-24 23:20:00 | 130460 |
| 412 | PAID | 2026-06-17 20:40:00 | 129436 |
| 412 | PAID | 2026-05-20 10:00:00 | 125340 |
31 total · 28 개 entry 생략
clustered lookup에 전달되는 primary key130460
total_cents absent from secondary entryPRIMARY
Derived · fixtureExact clustered row
- id
- 130460
- customer_id
- 412
- status
- PAID
- ordered_at
- 2026-06-24 23:20:00
- total_cents
- 113740
ORDER BY와 LIMIT 20 결과
| id | customer_id | status | ordered_at | total_cents |
|---|---|---|---|---|
| 130460 | 412 | PAID | 2026-06-24 23:20:00 | 113740 |
| 129436 | 412 | PAID | 2026-06-17 20:40:00 | 4684 |
| 125340 | 412 | PAID | 2026-05-20 10:00:00 | 68460 |
| 124316 | 412 | PAID | 2026-05-13 07:20:00 | 209404 |
| 120220 | 412 | PAID | 2026-04-14 20:40:00 | 23180 |
| 119196 | 412 | PAID | 2026-04-07 18:00:00 | 164124 |
| 115100 | 412 | PAID | 2026-03-10 07:20:00 | 227900 |
| 114076 | 412 | PAID | 2026-03-03 04:40:00 | 118844 |
| 109980 | 412 | PAID | 2026-02-02 18:00:00 | 182620 |
| 108956 | 412 | PAID | 2026-01-26 15:20:00 | 73564 |
| 104860 | 412 | PAID | 2025-12-29 04:40:00 | 137340 |
| 103836 | 412 | PAID | 2025-12-22 02:00:00 | 28284 |
| 99740 | 412 | PAID | 2025-11-23 15:20:00 | 92060 |
| 98716 | 412 | PAID | 2025-11-16 12:40:00 | 233004 |
| 94620 | 412 | PAID | 2025-10-19 02:00:00 | 46780 |
| 93596 | 412 | PAID | 2025-10-11 23:20:00 | 187724 |
| 89500 | 412 | PAID | 2025-09-13 12:40:00 | 1500 |
| 88476 | 412 | PAID | 2025-09-06 10:00:00 | 142444 |
| 84380 | 412 | PAID | 2025-08-08 23:20:00 | 206220 |
| 83356 | 412 | PAID | 2025-08-01 20:40:00 | 97164 |
sha256 · f3b6a116a0d644412cd60167a96e4e8d628adbe75106f53d78c3893fef401a8b01 / 17