모두의 문제집

SQLP

시험 직전 요약장

판단 기준과 헷갈리는 개념, 대표 예제를 짧게 확인하세요.

이론 목록

Nested Loops Join 기본 원리: Outer·Inner·반복 탐색

원래 이론 →

판단 기준

혼동정확한 기준
작은 원본 Table이 항상 OuterFilter 후 Row Source와 Inner 비용이 기준
두 번째 자식 하나가 항상 Inner 전체최신 Plan에서는 Index ROWID 생성과 Table Access가 분리될 수 있음
BATCHED면 Random Access가 사라짐ROWID를 Batch로 묶어 Block 방문을 개선하는 방식
Inner Index가 있으면 NL은 항상 빠름Starts·Leaf Range·ROWID·Match 수를 함께 확인
Inner Starts는 항상 Outer A-Rows와 정확히 같음기본 관계지만 Filter·Batching·Caching·Plan 구조를 확인
E-Rows와 A-Rows는 그대로 비교반복 Row Source는 Total 또는 Per-Start 단위를 맞춤
첫 행이 빠르면 전체도 빠름First Row와 Full Fetch 계약을 분리
NL Plan이면 결과 순서가 보장됨결과 순서는 ORDER BY만 보장
BATCHED Table Buffers가 크면 Index만 RebuildOuter 규모·Filter·CF·Index Column·Join Method를 종합
Adaptive Plan이면 Statistics 문제 해결Runtime 선택일 뿐 반복 오류의 근본 원인은 별도 개선
이 부분의 원문 →

헷갈리는 개념

공정한 비교 조건입니다.

예시·텍스트
Plan A
  첫 20행 0.05초
  전체 100만행 30초

Plan B
  첫 20행 0.5초
  전체 100만행 8초

업무 목표에 따라 우수 Plan이 달라집니다.

측정 시 통일합니다.

  • 같은 Bind 값과 Data Type
  • 같은 Client Fetch Size
  • 같은 최종 Fetch Row 수
  • 같은 Cache·Statistics·Optimizer 환경
  • 첫 행 또는 End-of-Fetch 목표
  • 같은 결과 행·정렬 의미

ORDER BY가 없으면 NL Plan의 생산 순서가 결과 순서를 보장하지 않습니다.

이 부분의 원문 →

대표 계산·예제

예시·텍스트
ORDERS
  한 행 = 주문 한 건

CUSTOMERS
  한 행 = 고객 한 명
  CUSTOMER_ID Primary Key

최근 PAID 주문과 고객명을 조회합니다.

SQL
SELECT /*+ GATHER_PLAN_STATISTICS */
       o.order_id,
       o.order_date,
       c.customer_name
FROM   orders o
JOIN   customers c
  ON   c.customer_id = o.customer_id
WHERE  o.order_date >= :from_date
AND    o.status = 'PAID';

ORDERS가 Outer이고 CUSTOMERS가 Inner인 논리 흐름입니다.

예시·텍스트
1. 조건을 만족하는 ORDERS Row 한 건을 읽음
2. CUSTOMER_ID를 얻음
3. CUSTOMERS_PK를 Probe
4. 고객 Row를 주문 Row와 결합
5. 다음 주문에 대해 반복

Outer가 3행이고 고객 Key가 유일하면 다음과 같은 방향입니다.

예시·텍스트
Outer A-Rows            3
CUSTOMERS_PK Starts     3
Inner 평균 Match        1
최종 Join A-Rows        3
이 부분의 원문 →
이 단원 최대 5문제 →

내 최근 연습 오답

현재 브라우저의 연습 채점 기록에서 공개된 단원과 연결된 오답을 확인합니다.

학습 기록 →

오답 기록을 확인하고 있습니다.