Brain184. 파티션 프루닝 (Partition Pruning) - 파티션 가지치기
핵심 인사이트: 100층짜리 백화점에서 내 차를 찾을 때, 주차증에 'B3층'이라고 적혀 있다면 B1, B2층은 쳐다보지도 않고 곧장 B3층으로 내려간다. 파티션 프루닝은 쿼리의
WHERE조건을 본 옵티마이저가, 쓸데없는 파티션(서랍)은 닫아버리고 필요한 파티션만 '쏙' 골라서 읽는 핵심 최적화 원리다.
Ⅰ. 파티션 프루닝 (Partition Pruning)의 개념
'Pruning(가지치기)'이라는 뜻 그대로, 데이터베이스 옵티마이저가 쿼리를 실행할 때 테이블 전체를 스캔하지 않고, WHERE 조건절을 분석하여 데이터가 존재할 가능성이 전혀 없는 파티션들을 실행 계획에서 아예 제외(제거)해 버리는 최적화 기법입니다. 파티셔닝을 하는 가장 결정적인 이유(성능 향상)가 바로 이 프루닝 때문입니다.
Ⅱ. 동작 방식 (어떻게 가지치기를 하는가?)
[ 5년 치(2020~2024) 데이터가 연도별로 파티셔닝된 테이블 ]
SELECT SUM(amount)
FROM sales_history
WHERE order_date >= TO_DATE('2024-05-01', 'YYYY-MM-DD');
- 옵티마이저가
WHERE order_date조건을 확인합니다. (order_date가 파티션 키임을 인지) - 테이블 메타데이터를 뒤져서 2020년~2023년 파티션에는 저 날짜의 데이터가 "물리적으로 존재할 수 없음"을 판단합니다.
- 실행 계획(Execution Plan)에서 2020~2023년 파티션을 통째로 날려버리고(Pruning), 오직 2024년 파티션 1개만 스캔(Partition Range Single)하도록 지시합니다. ➔ I/O가 80% 감소!
Ⅲ. 파티션 프루닝의 종류
| 구분 | 설명 |
|---|---|
| 정적 프루닝 (Static Pruning) | 쿼리에 상수 값(예: '2024-05-01')이 박혀 있어서, SQL을 파싱(Parsing)하고 컴파일하는 시점에 이미 어떤 파티션을 읽을지 확정되는 방식입니다. |
| 동적 프루닝 (Dynamic Pruning) | 쿼리 내부에 바인드 변수(:var)를 사용하거나, 조인(Join) 과정에서 상대 테이블의 값에 따라 읽어야 할 파티션이 런타임(실행 시점)에 동적으로 결정되는 방식입니다. (고급 최적화) |
Ⅳ. 프루닝이 실패하는 치명적 안티 패턴 (주의사항)
개발자가 코드를 잘못 짜면 프루닝이 작동하지 않아(Full Partition Scan 발생) 시스템이 멈춰버립니다.
- 파티션 키 가공:
WHERE TO_CHAR(order_date, 'YYYY') = '2024'- 컬럼을 함수로 감싸버리면 옵티마이저가 원래 값을 잃어버려 프루닝을 포기합니다. 반드시
WHERE order_date >= '2024-01-01' AND ...형태로 원형을 유지해야 합니다.
- 컬럼을 함수로 감싸버리면 옵티마이저가 원래 값을 잃어버려 프루닝을 포기합니다. 반드시
- 묵시적 형변환: 파티션 키는
VARCHAR2타입인데,WHERE order_date = 20240101처럼 숫자형으로 조회하면 내부적으로 함수가 적용되어 프루닝이 풀려버립니다.
📢 섹션 요약 비유: 수박을 1박스 샀는데 '가운데 줄 수박만 달다'는 정보(조건)가 있습니다. 바보(프루닝 실패)는 100통의 수박을 다 쪼개서 맛을 보지만, 천재(파티션 프루닝)는 윗줄과 아랫줄 수박(불필요 파티션)은 칼도 대지 않고 바로 쓰레기통에 버린 뒤 오직 가운데 줄 수박만 꺼내서 먹는 쾌속 작업입니다.