💡 핵심 인사이트
옵티마이저(Optimizer)는 데이터베이스의 **뇌(두뇌)**입니다. 사용자가 "어떤 데이터를 원한다"고 SQL을 던지면, DB 내의 수많은 테이블과 인덱스를 살펴보고 가장 빠르고 비용이 적게 드는 '최적의 데이터 탐색 경로(실행 계획, Execution Plan)'를 스스로 짜내는 천재 네비게이션입니다.

Ⅰ. 옵티마이저의 역할

우리가 작성하는 SQL은 비절차적 언어입니다. 즉 "강남역으로 가줘(What)"만 명시할 뿐, "내부순환로를 타서 어디서 빠져라(How)"라는 경로는 명시하지 않습니다. 이 '어떻게 찾을 것인가(How)'를 결정하는 주체가 바로 DBMS 핵심 엔진인 옵티마이저입니다.

• 입력: 파서(Parser)가 문법 검사를 마친 파스 트리(Parse Tree).
• 출력: 테이블을 읽는 순서, 인덱스 사용 여부, 조인 알고리즘 등을 담은 실행 계획 (Execution Plan).

똑같은 결과가 나오는 SQL이라도, 옵티마이저가 A테이블을 먼저 읽느냐 B테이블을 먼저 읽느냐에 따라 0.1초 만에 끝날 작업이 10시간이 걸릴 수도 있습니다.

Ⅱ. 옵티마이저의 2가지 종류

옵티마이저는 어떤 기준으로 길을 찾느냐에 따라 크게 두 세대로 나뉩니다.

1. 규칙 기반 옵티마이저 (RBO, Rule-Based Optimizer)

• 개념: 과거에 쓰던 구형 방식입니다. 시스템에 미리 정해진 우선순위 규칙(Rule) 15가지에 따라 맹목적으로 기계적인 실행 계획을 짭니다.
• 판단 기준 예시: "무조건 인덱스가 풀 스캔(Full Scan)보다 빠르다", "기본키(PK)를 타는 것이 가장 점수가 높다."
• 한계: 데이터가 10건밖에 없는 테이블은 인덱스를 타는 것보다 그냥 풀 스캔으로 다 읽어버리는 게 훨씬 빠른데도, RBO는 융통성 없이 "인덱스가 있으니 인덱스를 타야지!"라며 비효율적인 길을 선택합니다. (현재는 거의 폐기됨)

2. 비용 기반 옵티마이저 (CBO, Cost-Based Optimizer)

• 개념: 현대 오라클, MySQL 등이 사용하는 똑똑한 방식입니다. 목적지까지 갈 수 있는 여러 가지 경로의 '예상 비용(Cost)'을 전부 수치로 계산해 본 뒤, 가장 비용이 적게(빠르게) 드는 경로를 선택합니다.
• 판단 기준: 통계 정보 (통계 딕셔너리).
  • 테이블의 총 행(튜플) 수는 몇 개인지.
  • 디스크 블록 수는 몇 개인지.
  • 컬럼 값의 분포도(Density)는 어떤지.
• 동작 방식: 통계 데이터를 바탕으로 "A테이블 데이터가 1억 건이나 되네? 인덱스를 타면 오히려 I/O가 폭발하겠군. 풀 스캔을 때리자!"라고 스스로 지능적인 판단을 내립니다.

Ⅲ. 통계 정보 관리의 중요성

비용 기반 옵티마이저(CBO)가 천재적인 길 찾기를 하려면, 현재 도로 상황을 알려주는 '최신 통계 정보'가 생명입니다.

만약 테이블에 데이터가 100만 건 추가되었는데 통계 정보 갱신(예: Oracle의 ANALYZE 또는 DBMS_STATS 패키지 실행)을 안 해주면, 옵티마이저는 옛날 지도를 보고 "아직 데이터가 10건밖에 없네?"라고 착각하여 최악의 경로를 선택하게 됩니다. 이를 **'통계 정보의 노후화로 인한 실행 계획 틀어짐'**이라고 하며, DBA들이 가장 골치 아파하는 성능 장애의 원인입니다.

📢 섹션 요약 비유: RBO는 "무조건 고속도로가 국도보다 빠르다"는 옛날 공식만 외우고 다니는 초보 운전자입니다. 반면 CBO는 실시간 교통량, 톨게이트 비용, 신호등 개수(통계 정보)를 모두 수학적으로 계산하여, 명절에는 오히려 고속도로를 피해 국도로 안내하는 티맵(T-Map)이나 카카오내비 같은 스마트 인공지능입니다.