SQLP
시험 직전 요약장
판단 기준과 헷갈리는 개념, 대표 예제를 짧게 확인하세요.
IN·BETWEEN·LIKE 조건의 인덱스 탐색: 반복 Probe와 연속 범위
원래 이론 →판단 기준
Oracle 26ai는 단일 Expression IN 목록에 많은 값을 허용하지만, 문법상 허용된다는 사실과 효율적인 실행은 다릅니다.
긴 목록의 문제입니다.
- 많은 Range Probe와 Starts
- Parse·
Bind 전달 비용 - 값별 편중
- 큰 Table 후보·Table Access
- SQL Text·
Cursor 관리 - Application에서 목록 생성 오류
- Partition·
Join 대안과의 비용 차이
대안 후보입니다.
- Temporary Table 또는 Staging Table에 값 저장 후 Join
- Collection·
Table Function 기반 Join - 업무 Key Table과 Semijoin
- Batch 단위 분할
- 조건 조합에 맞는 복합 Index
- Full·
Partition Scan
선택은 실제 결과·작업량·운영 안정성으로 결정합니다.
헷갈리는 개념
표를 좌우로 밀어 나머지 열을 확인하세요. 키보드: ←·→, Home·End
| 혼동 | 정확한 기준 |
|---|---|
| IN은 등치이므로 한 번만 탐색한다 | 값별 여러 Range Probe가 생길 수 있다 |
| SQL에 IN이 있으면 항상 INLIST ITERATOR다 | Subquery·Partition·Cost·Transformation에 따라 다르다 |
| Starts는 항상 IN 값 수다 | 전체 Iterator 구조와 실행 중단을 함께 본다 |
| IN 목록에 NULL을 넣으면 NULL Row도 조회된다 | NULL Row는 IS NULL을 명시한다 |
| NOT IN 목록의 NULL은 무시된다 | UNKNOWN 때문에 결과가 사라질 수 있다 |
| BETWEEN은 양쪽을 제외한다 | 하한·상한을 모두 포함한다 |
| 날짜 BETWEEN의 마지막 날짜가 하루 전체다 | 상한의 시간 값까지만 포함한다 |
| BETWEEN은 IN으로 바꾸면 항상 빨라진다 | 동일한 이산 Domain과 실측 이득이 필요하다 |
LIKE의 _는 임의 길이 문자열이다 | 정확히 한 문자를 의미한다 |
| Leading Wildcard도 Prefix Range를 만든다 | 첫 Key를 특정하기 어려워 좁은 Range에 불리하다 |
대표 계산·예제
예를 들어 한 고객의 전체 주문이 20행이라면 고객 Prefix를 한 번 읽고 Status를 Filter하는 편이 상태별 반복 Probe보다 저렴할 수 있습니다.
내 최근 연습 오답
현재 브라우저의 연습 채점 기록에서 공개된 단원과 연결된 오답을 확인합니다.
오답 기록을 확인하고 있습니다.