SQLP
시험 직전 요약장
판단 기준과 헷갈리는 개념, 대표 예제를 짧게 확인하세요.
옵티마이저의 한계와 역할 분담: 좋은 판단 조건 만들기
원래 이론 →판단 기준
옵티마이저는 Database와 SQL에 표현된 정보를 이용해 후보 실행계획을 만들고 Cost를 비교합니다.
표를 좌우로 밀어 나머지 열을 확인하세요. 키보드: ←·→, Home·End
| 옵티마이저가 활용할 수 있는 정보 | 활용 예시와 주의점 |
|---|---|
| SQL의 테이블·조건·조인·정렬·결과 제한 | 가능한 Access Path, Join Order, Join Method와 처리 범위 판단 |
| 테이블·컬럼·인덱스 통계 | Selectivity, Cardinality, I/O·CPU Cost 추정 |
| PK·UK·FK·NOT NULL 등 제약조건 | 검증되고 신뢰할 수 있는 관계를 Cardinality 추정과 일부 Transformation에 활용 |
| 존재하며 사용 가능한 인덱스·파티션 | 실제로 선택할 수 있는 물리적 Access Path 구성 |
| Materialized View와 Query Rewrite 설정 | Rewrite가 활성화되고 적용 조건을 만족할 때 대체 후보로 검토 |
| Literal과 Bind 정보 | Hard Parse 시점의 값과 통계를 이용한 선택도 추정에 활용 가능 |
| Optimizer Goal과 관련 설정 | 전체 처리량, 초기 응답시간, 기능 사용 범위 등에 영향 |
| Oracle 버전과 기능 | 사용할 수 있는 Transformation, 적응형 기능, 비용 모델에 영향 |
이 정보가 존재한다고 해서 항상 정확한 계획이 나오는 것은 아닙니다. 통계가 오래되었거나 제약조건이 실제 업무 규칙과 다르거나, Bind 값별 분포 차이가 크면 추정이 실제와 달라질 수 있습니다.
헷갈리는 개념
표를 좌우로 밀어 나머지 열을 확인하세요. 키보드: ←·→, Home·End
| 혼동하기 쉬운 판단 | 정확한 기준 |
|---|---|
| 옵티마이저가 화면에서 필요한 행 수를 알아서 판단한다 | SQL과 애플리케이션이 필요한 결과 범위를 명시한다 |
| 적절한 인덱스가 없으면 옵티마이저가 즉석에서 만든다 | 일반 최적화에서는 현재 존재하고 사용 가능한 경로만 후보가 된다 |
| Automatic Indexing과 일반 옵티마이저는 같은 기능이다 | Automatic Indexing은 후보 생성·검증을 수행하는 별도 관리 기능이다 |
| 최신 통계만 있으면 항상 좋은 계획이 나온다 | SQL 구조, 제약조건, 물리 구조, Bind 분포와 Optimizer Goal도 영향을 준다 |
| Bind를 사용하면 모든 값에 같은 계획이 항상 최적이다 | 값별 분포가 다르면 대표값별 실제 작업량을 검증해야 한다 |
| Hint를 작성하면 반드시 적용된다 | 적용 가능성·충돌·대상 Query Block을 확인하고 실제 계획으로 검증한다 |
| Hint로 특정 계획이 나오면 튜닝이 끝난다 | 근본 원인과 데이터 변화에 따른 유지보수 위험까지 평가한다 |
| 안정성은 하나의 계획을 영구 고정하는 것이다 | 검증된 계획을 예측 가능하게 관리하는 것이며 여러 Accepted Plan도 가능하다 |
| Cost가 가장 낮은 계획은 실제로 항상 가장 빠르다 | Cost는 추정값이므로 실제 행 수와 실행 통계로 검증한다 |
| SQL 성능 문제는 모두 SQL 작성자의 책임이다 | SQL, 통계, 데이터 모델, 애플리케이션, 동시성, 시스템 문제를 구분한다 |
내 최근 연습 오답
현재 브라우저의 연습 채점 기록에서 공개된 단원과 연결된 오답을 확인합니다.
오답 기록을 확인하고 있습니다.