옵티마이저

(RealMySQL의 3챕터 아키텍처를 가져왔다. 해당 아키텍처는 볼 때마다 훌륭하다.)

옵티마이저

SQL을 가장 효율적으로 실행하기 위해 실행 계획을 세우는 DBMS 내부 엔진이다.
쉽게 말하면, SELECT ... 같은 SQL을 날린다면, DB가 "어떤 인덱스를 탈까? 풀스캔 할까? 어떤 순서로 조인하지?"를 자동으로 계산해서 실행 계획을 만들어주는 "두뇌"라고 보면 된다.

역할

• 여러 실행 방법 중 최적의 경로 선택
  - 인덱스를 사용할지, 풀스캔할지
  • 조인을 어떤 방식(NL Join, Hash Join, Sort-Merge join등)으로 할지
  • 정렬 할지/말지
• 비용 계산
  - I/O(디스크 읽기 횟수)
  • CPU 사용량
  • 네트워크 비용

이러한 사항들을 고려해서 가장 빨리 끝날 확률이 높은 실행계획을 고른다.

종류

1. 규칙 기반 옵티마이저 RBO

• 단순히 규칙에 따라 실행계획 결정
• 인덱스가 있으면 무조건 인덱스 먼저 진행하는 단순한 규칙이다.
• 지금은 거~~~의 안 씀

2. 비용 기반 옵티마이저 CBO

• 현재 주 방식
• 통계 정보(테이블 행 수, 인덱스 분포, 카디널리티 등)를 기반으로 실행 비용을 계산
• 최소 비용의 실행계획을 고른다
• 오라클, MySQL, PostgreSQL 다 CBO기반이다.

쉽게

SELECT *
FROM orders
WHERE customer_id = 10;

옵션 1 : 테이블 전체 스캔 (FullTableScan) -> 행이 수십 개면 이게 더 빠름 무조건 빠름.
옵션 2 : 인덱스 스캔(Index Scan) -> 행이 늘어날수록 이게 더 빠름.
customer_id 인덱스 있다면 이게 훠~~얼씬 빠름.

즉, 옵티마이저는 통계 정보를 보고 자동으로 더 효율적인 것을 고른다.

MySQL vs Oracle 옵티마이저 비교

1. 공통점

• 둘 다 CBO (Cost-Based Optimizer) 기반
• SQL 실행 시 여러 실행 경로를 시뮬레이션 후, 최소 비용 경로 선택
• 통계 정보(테이블/인덱스 분포, 카디널리티, 행 수, I/O 비용 등)를 활용
• 실행계획 확인 가능 (EXPLAIN in MySQL, EXPLAIN PLAN in Oracle)

---

2. MySQL 옵티마이저

• 특징

  • 비교적 단순한 CBO
  • 통계 정보가 정확하지 않아도 대충 실행 가능 → "가볍다"는 장점
  • 실행계획 캐싱(X) → 매 쿼리마다 계획 수립
  • 힌트는 있지만 제한적 (STRAIGHT_JOIN, FORCE INDEX, USE INDEX 등)

• 장단점

  • 장점: 단순해서 오버헤드 적음, 중소규모 트래픽 환경에서 빠름
  • 단점: 복잡한 조인/대규모 데이터에서 최적화 미흡, 통계 정보 활용이 제한적

• 실행계획 확인

  EXPLAIN SELECT ...;
  EXPLAIN ANALYZE SELECT ...;  -- MySQL 8.0부터 실행 시간까지 확인 가능

3. Oracle 옵티마이저

• 특징
  - 고도화된 CBO (Cost-Based Optimizer)
  - 매우 정교한 통계 정보 기반 → 테이블, 컬럼, 인덱스, 파티션 등 상세 관리
  - 실행계획 캐싱(O) → 같은 SQL은 재사용 (Library Cache)
  - 다양한 옵티마이저 힌트 제공 (INDEX, FULL, PARALLEL, LEADING, USE_NL, USE_HASH 등 수백 개)

• 장단점

  	- 장점: 복잡한 쿼리/대규모 데이터에서 최적화 탁월
  
  	- 단점: 옵티마이저 동작이 무겁고, 통계 관리 비용이 큼 (ANALYZE, DBMS_STATS 필요)

• 실행계획 확인

EXPLAIN PLAN FOR SELECT ...;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

---

4. 비교 요약 표

항목	MySQL	Oracle
옵티마이저 방식	CBO (단순)	CBO (고도화)
통계 활용	제한적 (대략적)	정교함 (컬럼/인덱스/히스토그램 기반)
실행계획 캐싱	X (매번 새로 수립)	O (Library Cache 재사용)
힌트 지원	제한적 (USE INDEX, STRAIGHT_JOIN)	매우 다양 (INDEX, FULL, USE_HASH, ...)
성능 튜닝 난이도	단순	고급 (풍부한 기능, 하지만 복잡함)
적합한 환경	중소규모, 웹서비스, OLTP 중심	대규모 트랜잭션/분석, OLTP + OLAP 병행

---

5. 핵심 정리

• MySQL: 단순하고 가볍다. 옵티마이저가 단순하기 때문에 실무에서는 직접 EXPLAIN 확인 후 인덱스 설계/힌트로 조정해야 함.
• Oracle: 강력하고 정교하다. 하지만 "통계 관리 + 옵티마이저 힌트" 이해 없이는 비효율적인 실행계획이 나올 수 있음.

👉 결론

• MySQL → 스타트업/중소규모 시스템, 빠른 개발에 적합
• Oracle → 대기업/대규모 시스템, 정교한 튜닝 필요한 환경에 적합