SQL 처리 과정

• 과거 DB(xBase) → 처리 절차를 프로그래머가 직접 작성
• 현재 (SQL) → 결과 집합을 정의, 과정은 옵티마이저가 설정

SQL Parsing

캐싱되는 영역 = 라이브러리 캐시(oracle) , 프로시저 캐시(sql server)

graph TD;

A[SQL]-->B[Syntax check];
B-->C[Semantic check];
C-->D[Access auth check];
D-->E[Cache];
E-->F[Execution plan];
E-->G[Soft parsing];
E-->H[Hard parsing];

F[Optimization];

G-->I[Execution];
H-->F-->I;
DB[DB I/O];
F-->DB;

최적화가 필요한 이유

SELECT * FROM A
JOIN B ON A.id = B.id
JOIN C ON B.id = C.id
JOIN D ON C.id = D.id
JOIN E ON D.id = E.id;

위와같은 SQL 을 날릴 시 5! 의 실행계획 + 각 단계별 Join방식 을 평가해야됨으로 굉장히 무거운 연산입니다.

해당 평가계획에 대한 캐싱을 효과적으로 이용하기 위해 이전에 지우님이 설명 해 주신대로 바인드 변수를 이용하면 좋습니다.

• 바인드 변수로 프로시저 생성 시
  • → 생성 시점에서 최적화
  • → 반복 실행시 조건절에 들어온 컬럼 데이터가 Dictionary에 정의되어있어도 활용 하지 못함
• ‘Peeking’(Oracle 9+)과 ‘Sniffing’(SQL server)
  • 첫번 째 수행 될 바인드 변수 값으로 컬럼 분포 결정
  • → But → 분포가 달라 질 시 성능 저하
• Adaptive Cursor Sharing (Oracle 11g +)
  • 입력 변수 값 분포에 따라 다른 실행계획 생성