SQLP
시험 직전 요약장
판단 기준과 헷갈리는 개념, 대표 예제를 짧게 확인하세요.
집계와 중복 제거: SORT·HASH Operation 비교
원래 이론 →판단 기준
표를 좌우로 밀어 나머지 열을 확인하세요. 키보드: ←·→, Home·End
| 잘못된 판단 | 정확한 판단 |
|---|---|
SORT AGGREGATE는 전체 입력을 ORDER BY처럼 정렬 | 전체 Aggregate 상태 계산 Operation |
| GROUP BY 결과는 자동으로 Group Key 순서 | 순서는 ORDER BY만 보장 |
| HASH GROUP BY는 항상 SORT보다 빠름 | Group 수·Memory·TEMP·후속 Sort 비교 |
| NOSORT가 보이면 항상 최적 | Index Scan·Table Access 포함 전체 비용 확인 |
| DISTINCT는 가벼운 문법 | 입력량·Unique Key 수만큼 큰 Workarea 가능 |
| SORT UNIQUE 결과는 정렬 보장 | 명시적 ORDER BY 없이는 보장하지 않음 |
| UNION을 UNION ALL로 바꾸면 항상 동일 | 중복 보존 의미가 달라질 수 있음 |
| NULL마다 별도 Group 생성 | GROUP BY·DISTINCT에서는 하나로 축약 |
| Group By가 두 번이면 불필요 | 병렬 부분·최종 집계일 수 있음 |
| Spill은 Memory만 늘리면 해결 | 입력 축소·통계·Row 폭·Skew도 점검 |
헷갈리는 개념
표를 좌우로 밀어 나머지 열을 확인하세요. 키보드: ←·→, Home·End
| 항목 | SORT GROUP BY | HASH GROUP BY |
|---|---|---|
| 핵심 구조 | Group Key 정렬 후 연속 집계 | Hash Table에 Group 상태 누적 |
| Memory | Sort Workarea | Hash Workarea |
| Disk 사용 | Sort Run을 TEMP에 기록 가능 | Hash Partition을 TEMP에 기록 가능 |
| 입력 순서 활용 | 이미 Group Key 순서면 NOSORT 가능 | 정렬 순서 자체는 직접 이점이 아님 |
| 출력 순서 | 우연히 Key 순서처럼 보일 수 있으나 보장 아님 | Group Key 순서 미보장 |
| 후속 ORDER BY | Key·방향이 호환되는지 확인 | 별도 Sort가 생길 가능성이 큼 |
| 주요 위험 | Wide Sort·TEMP Spill | Group 수 과소 추정·Hash Spill |
| 유리한 전형 | 입력 순서 활용·후속 같은 정렬 | 순서 불필요·Memory에 Group 상태 수용 |
Optimizer는 예상 입력 행 수, Group Cardinality, Row 폭, Memory, 입력 순서와 후속 Operation을 함께 평가합니다. HASH GROUP BY가 항상 빠르다, SORT GROUP BY가 항상 느리다처럼 단정하지 않습니다.
내 최근 연습 오답
현재 브라우저의 연습 채점 기록에서 공개된 단원과 연결된 오답을 확인합니다.
오답 기록을 확인하고 있습니다.