실행 계획 읽기

-------------------------------------------------------------------------
| 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 UNIQUE SCAN         | PK_DEPT        |    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;

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블록 읽음

1. TABLE ACCESS FULL + 대량 행:
   → 인덱스가 없거나, 인덱스를 사용하지 못하는 쿼리
   → WHERE에 함수 적용, 타입 불일치 등 확인

2. 예상 Rows와 실제 Rows의 큰 차이:
   Oracle:  E-Rows=1 vs A-Rows=100000
   MySQL:   EXPLAIN rows=1 vs EXPLAIN ANALYZE rows=100000
   → 통계 정보가 오래되었을 가능성
   → ANALYZE TABLE 또는 DBMS_STATS.GATHER 실행

3. NESTED LOOPS + 대량 데이터:
   → HASH JOIN이 더 적합할 수 있음
   → 내부 테이블 인덱스 누락 확인

4. SORT ORDER BY + 큰 Cost:
   → ORDER BY 컬럼에 인덱스 추가 검토
   → 커버링 인덱스로 정렬 회피 가능 여부 확인

5. filter 조건이 access 대신 사용:
   → 인덱스를 통해 접근하지 않고 전체 스캔 후 필터링
   → 인덱스 설계 재검토 필요

-- 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 = 카디널리티)
  * 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;

-- Optimizer Hint (MySQL 8.0+)
SELECT /*+ NO_INDEX(e idx_dept) */ * FROM employees e;
SELECT /*+ HASH_JOIN(e d) */ e.name, d.dept_name
FROM employees e JOIN departments d 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 등)