실행 계획 읽기

-------------------------------------------------------------------------
| Id | Operation                    | Name           | Rows | Cost (%CPU)|
-------------------------------------------------------------------------
|  0 | SELECT STATEMENT             |                |   15 |    4  (0)  |
|  1 |  NESTED LOOPS                |                |   15 |    4  (0)  |
|  2 |   TABLE ACCESS BY INDEX ROWID| DEPARTMENTS    |    1 |    2  (0)  |
|* 3 |    INDEX RANGE SCAN          | IDX_DEPT_NAME  |    1 |    1  (0)  |
|  4 |   TABLE ACCESS BY INDEX ROWID| EMPLOYEES      |   15 |    2  (0)  |
|* 5 |    INDEX RANGE SCAN          | IDX_EMP_DEPT   |   15 |    1  (0)  |
-------------------------------------------------------------------------

Predicate Information:
  3 - access("D"."DEPT_NAME"='개발팀')
  5 - access("E"."DEPT_ID"="D"."ID")

Id:    Operation의 고유 번호 (* 표시 = Predicate 존재)
Operation: 수행하는 작업 (스캔 방식, 조인 방식 등)
Name:  대상 객체 (테이블명, 인덱스명)
Rows:  옵티마이저가 예측한 반환 행 수 (Cardinality)
Bytes: 예측한 반환 데이터 크기
Cost:  옵티마이저가 추정한 상대 비용
Time:  비용 모델로 추정한 시간 표시, 실제 시간과 다를 수 있음

Predicate Information
  access: 접근 경로나 조인 키로 사용된 조건
  filter: 읽은 행에 추가로 적용하는 조건

SORT ORDER BY:     ORDER BY 절 처리 (메모리/디스크 정렬)
SORT GROUP BY:     GROUP BY 절 처리
HASH GROUP BY:     해시 기반 GROUP BY (정렬 불필요)
SORT AGGREGATE:    집계 함수 (COUNT, SUM 등)
FILTER:            WHERE 조건으로 행 필터링
VIEW:              인라인 뷰 또는 뷰 처리
UNION-ALL:         UNION ALL 결합
HASH UNIQUE:       DISTINCT 처리 (해시 기반)
COUNT STOPKEY:     ROWNUM 조건으로 조기 종료
BUFFER SORT:       중간 결과를 임시 버퍼에 정렬
INLIST ITERATOR:   IN 리스트의 각 값에 대해 반복

+----+------+-------+------+---------+------+------+-------------+
| id | type | table | key  | key_len | ref  | rows | Extra       |
+----+------+-------+------+---------+------+------+-------------+
|  1 | ref  | d     |idx_nm| 102     |const |    1 | Using where |
|  1 | ref  | e     |idx_dp| 4       |d.id  |   15 | NULL        |
+----+------+-------+------+---------+------+------+-------------+

-- 예상 실행 계획
EXPLAIN SELECT * FROM orders WHERE user_id = 1001;

-- 실행 계획 + 실제 실행 통계
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 1001;

-- 상세 출력
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT * FROM orders WHERE user_id = 1001;

BEGIN;
EXPLAIN (ANALYZE, BUFFERS)
UPDATE orders SET status = 'done' WHERE id = 1001;
ROLLBACK;

Index Scan using idx_orders_user on orders
    (cost=0.42..8.44 rows=15 width=120)
    (actual time=0.010..0.025 rows=12 loops=1)
    Index Cond: (user_id = 1001)
    Buffers: shared hit=4
Planning Time: 0.150 ms
Execution Time: 0.045 ms

해석:
  cost=0.42..8.44: 시작 비용..전체 비용
  rows=15:         예상 행 수
  actual rows=12:  실제 행 수
  loops=1:         실행 횟수
  Buffers shared hit=4: 버퍼 캐시에서 4블록 읽음

-- Oracle
EXEC DBMS_STATS.GATHER_TABLE_STATS('SCHEMA', 'ORDERS');
EXEC DBMS_STATS.GATHER_INDEX_STATS('SCHEMA', 'IDX_ORDERS');
EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SCHEMA');

-- MySQL
ANALYZE TABLE orders;

-- PostgreSQL
ANALYZE orders;
-- VACUUM ANALYZE orders; (VACUUM과 동시에)

테이블 통계:
  * 행 수 (NUM_ROWS)
  * 블록 수 (BLOCKS)
  * 평균 행 길이 (AVG_ROW_LEN)

컬럼 통계:
  * 고유 값 수 (NUM_DISTINCT = NDV/컬럼 카디널리티)
  * NULL 비율 (NUM_NULLS)
  * 최소값/최대값 (LOW_VALUE, HIGH_VALUE)
  * 히스토그램 (데이터 분포 정보)

인덱스 통계:
  * 리프 블록 수 (LEAF_BLOCKS)
  * 트리 높이 (BLEVEL)
  * 클러스터링 팩터 (CLUSTERING_FACTOR)

-- 풀 스캔 강제
SELECT /*+ FULL(e) */ * FROM employees e WHERE dept_id = 10;

-- 인덱스 사용 강제
SELECT /*+ INDEX(e IDX_EMP_DEPT) */ * FROM employees e WHERE dept_id = 10;

-- 조인 방식 강제
SELECT /*+ USE_NL(e d) */ e.name, d.dept_name
FROM employees e JOIN departments d ON e.dept_id = d.id;

SELECT /*+ USE_HASH(e d) */ e.name, d.dept_name
FROM employees e JOIN departments d ON e.dept_id = d.id;

-- 조인 순서 강제
SELECT /*+ ORDERED */ e.name, d.dept_name
FROM departments d JOIN employees e ON e.dept_id = d.id;

-- 병렬 처리
SELECT /*+ PARALLEL(orders, 4) */ COUNT(*) FROM orders;

-- 인덱스 사용 강제
SELECT * FROM employees FORCE INDEX (idx_dept) WHERE dept_id = 10;

-- 인덱스 무시
SELECT * FROM employees IGNORE INDEX (idx_dept) WHERE dept_id = 10;

-- Index-level Optimizer Hint (MySQL 8.0.20+)
SELECT /*+ NO_INDEX(e idx_dept) */ * FROM employees e;

-- Join-order Optimizer Hint (MySQL 8.0+)
SELECT /*+ JOIN_ORDER(d, e) */ e.name, d.dept_name
FROM departments d JOIN employees e ON e.dept_id = d.id;

1. 힌트는 최후의 수단
   → 먼저 인덱스 추가, 통계 갱신, 쿼리 재작성 시도

2. 데이터 분포 변하면 힌트가 역효과
   → 소량일 때 NL → 데이터 증가 시 성능 저하

3. Oracle 힌트는 문법 오류 시 무시됨
   → 테이블 별칭과 일치해야 함!

4. PostgreSQL은 힌트 공식 미지원
   → pg_hint_plan 확장으로 유사 기능

-- 리터럴 값 직접 삽입:
SELECT * FROM orders WHERE user_id = 1001;  -- SQL #1
SELECT * FROM orders WHERE user_id = 1002;  -- SQL #2 (다른 SQL!)

-- 바인드 변수/준비된 문장 형태:
SELECT * FROM orders WHERE user_id = :uid;  -- 같은 SQL 텍스트로 재사용 가능성 증가

갑자기 느려진 쿼리 체크리스트:
  1. 통계 정보 갱신 여부
  2. 데이터 분포 변화 (히스토그램)
  3. 인덱스 삭제/변경 여부
  4. 옵티마이저 파라미터 변경
  5. 실행 계획 이전과 비교 (AWR 등)