핵심 원칙

힌트는 빠른 해결책이 아니라 실행 계획을 마지막으로 고정하는 선택이다

인덱스, 통계, SQL 구조를 먼저 바로잡고도 계획이 비효율적일 때만 힌트를 쓴다. 넣었다면 왜 필요한지 남기고, 실제 계획이 바뀌었는지 끝까지 검증해야 한다.

사용 순서

먼저 자동 선택을 건강하게 만든 뒤, 그래도 틀릴 때만 개입

1
기본 튜닝부터 인덱스 생성, 통계 갱신, SQL 구조 정리로 옵티마이저가 스스로 올바른 선택을 하게 만든다.
그래도 실행 계획이 비효율적일 때만 힌트를 검토
2
힌트는 강제값 좋아 보이는 한 번의 결과가 아니라, 이후 데이터 변화까지 떠안는 운영 선택으로 본다.
무엇을 고정하나

힌트는 접근 방식, 조인 방식, 처리 목표를 직접 바꾼다

접근 경로
INDEX / NO_INDEX / FULL 어떤 인덱스를 쓸지, 아예 피할지, 전체 스캔으로 갈지를 고정한다.
조인 전략
LEADING + USE_NL / USE_HASH / USE_MERGE 조인 순서와 방식을 묶어서 바꾸므로, 결과량과 정렬 상태에 따라 성능이 크게 달라진다.
처리 목표
FIRST_ROWS(n) ↔ ALL_ROWS 처음 몇 행을 빨리 줄지, 전체 처리량을 우선할지처럼 최적화 목표 자체를 바꾼다.
운영 의미

데이터가 바뀌면 좋은 힌트도 나빠질 수 있다

힌트는 현재 분포를 전제로 맞춘 결정이다 카디널리티와 데이터 분포가 바뀌면, 예전에 맞던 조인 방식이나 인덱스 선택이 오히려 병목이 될 수 있다.
분포 변화
예전 힌트와 충돌
재검토 필요
최종 검증

힌트는 조용히 무시될 수 있으니 실행 계획으로 확인한다

/*+ INDX(e IDX_EMP) */ INDEX가 아니라 INDX처럼 오타가 나면 에러보다 무시로 끝날 수 있다.
문법·대상 점검
실행 계획 확인
원한 계획인지 검증