Engine Atlas

MySQL 내부 임시 테이블 - RAM, mmap 오버플로, InnoDB 디스크 전환

GROUP BY · TempTable · filesort · LIMIT
MySQL 8.4.10captured evidence
English
학습 안내

이 Lab에서 답할 질문

같은 GROUP BY 결과를 만들면서 intermediate rows가 RAM, mmap overflow, InnoDB on-disk profile에서 어디에 저장되나요?

실행 엔진: MySQL 8.4.10
누가 실행하나요?

하나의 Session이 같은 aggregation SELECT를 세 가지 controlled profile에서 각각 실행합니다.

무엇을 고정하나요?

동일한 work_orders fixture, GROUP BY, ORDER BY, LIMIT 100과 결과 checksum을 유지합니다.

실행 SQL
SELECT
  account_id,
  status,
  bucket_id,
  COUNT(*) AS order_count,
  SUM(amount_cents) AS total_cents,
  MAX(payload) AS sample_payload
FROM work_orders
GROUP BY account_id, status, bucket_id
ORDER BY total_cents DESC, account_id, status, bucket_id
LIMIT 100;
무엇이 달라지나요?

internal temporary table의 allocation profile, memory counters와 modeled storage transition이 달라집니다.

무엇이 그대로인가요?

aggregate result rows, 정렬 기준과 최종 checksum은 세 profile 모두에서 동일합니다.

먼저 예측해 보세요

storage profile을 바꾸면 query 결과는 어떻게 되어야 할까요?

storage profile을 바꾸면 query 결과는 어떻게 되어야 할까요?

증거 미션

InnoDB on-disk profile의 storage profile 단계를 열어 어떤 captured 값이 이 분류를 만드는지 확인하세요.

어디를 보나요?
Storage evidence 패널에서 physical_ram high-water, physical_disk high-water, Created_tmp_disk_tables, temptable_use_mmap 설정을 함께 읽습니다.
이동할 화면
InnoDB on-disk · storage profile
무엇이 보여야 하나요?
확인할 관찰

이 profile에서 Created_tmp_disk_tables는 1이고 mmap은 비활성이며 physical_disk high-water는 baseline에서 올라가지 않습니다. 분류는 이 captured profile 설정과 counter로 성립하고, RAM에서 disk로 넘어가는 전환 그림은 Model로 남습니다.

근거 경계
Captured
profile 설정과 physical_ram·physical_disk high-water, Created_tmp_disk_tables
Model
정확한 row나 시각을 지정하지 않는 storage conversion boundary
Checkpoint · evidence로 설명하기Created_tmp_disk_tables 하나만으로 mmap 또는 InnoDB storage transition 전체를 단정할 수 있나요?답과 근거 확인

단정할 수 없습니다. Captured counters와 profile 설정은 관측 근거이고, 화면의 RAM·mmap·InnoDB 전환 설명은 명시적으로 Model 경계에 둡니다.

근거 경계
Captured
profile 설정과 statement counter 관측
Model
RAM·mmap·InnoDB storage transition 설명
이번 Lab의 핵심

temporary work를 볼 때 최종 rows와 중간 allocation을 분리하고, captured counters와 설명용 storage model을 섞지 않아야 합니다.

다음 연결

다음 Lab에서는 storage의 더 작은 단위인 secondary index entry, carried primary key, clustered row와 Buffer Pool page state를 추적합니다.

용어 확인
internal temporary table처음 다루는 Lab 05
GROUP BY, DISTINCT, ORDER BY 같은 작업을 위해 server가 statement 안에서 만들고 관리하는 중간 저장 구조입니다.
filesort처음 다루는 Lab 01
index order만으로 ORDER BY를 만족하지 못할 때 사용하는 MySQL의 별도 정렬 작업 이름이며, 반드시 disk file을 뜻하지는 않습니다.

01 · SOURCE

Exact SQL

1 active fragmentMySQLGROUP BY · ORDER BY · LIMIT 100
SELECT account_id, status, bucket_id, COUNT(*) AS order_count, SUM(amount_cents) AS total_cents, MAX(payload) AS sample_payload
FROM work_orders
GROUP BY account_id, status, bucket_id
ORDER BY total_cents DESC, account_id, status, bucket_id
LIMIT 100;
  1. source-scan
  2. temporary-work
  3. temporary-scan
  4. filesort
  5. limit
02 · FLOW

Native plan과 actual iterator

01 / 12
Active native operators5
limitlimit
TREE: -> Limit: 100 row(s) ANALYZE: -> Limit: 100 row(s) (actual time=222..222 rows=100 loops=1)TREE line 1; ANALYZE line 1
filesortsort
TREE: -> Sort: total_cents DESC, work_orders.account_id, work_orders.`status`, work_orders.bucket_id, limit input to 100 row(s) per chunk ANALYZE: -> Sort: total_cents DESC, work_orders.account_id, work_orders.`status`, work_orders.bucket_id, limit input to 100 row(s) per chunk (actual time=222..222 rows=100 loops=1)TREE line 2; ANALYZE line 2
temporary-scantable-scan
TREE: -> Table scan on <temporary> ANALYZE: -> Table scan on <temporary> (actual time=196..209 rows=65536 loops=1)TREE line 3; ANALYZE line 3
temporary-worktemp-table
TREE: -> Aggregate using temporary table ANALYZE: -> Aggregate using temporary table (actual time=196..196 rows=65536 loops=1)TREE line 4; ANALYZE line 4
source-scantable-scan
TREE: -> Table scan on work_orders (cost=15156 rows=128478) ANALYZE: -> Table scan on work_orders (cost=13513 rows=128478) (actual time=0.037..40.3 rows=131072 loops=1)TREE line 5; ANALYZE line 5
Exact execution detail

131072개 source row가 100개 result row로 줄어듭니다

이 SQL은 131072개 source row를 어떻게 100개 result row로 줄이는가?

GROUP BY output

Logical temporary rows

Derived · fixture
65536 rows65536 이 화면에서 생략
Active metrics4
source scan actual rows
131072 row
Captured
limit actual rows
100 row
Captured
execution rows examined
131172 row
Captured
execution rows sent
100 row
Captured
01 / 12