SQL 튜닝 실무 가이드: 성능을 10배 높이는 쿼리 작성법¶

본 프로젝트는 실무에서 자주 발생하는 비효율적인 SQL 패턴을 분석하고, 이를 최적화하여 데이터베이스 성능을 극적인 수준으로 개선하는 과정을 담고 있습니다.

단순히 쿼리를 실행하는 것을 넘어, 실행 계획(Execution Plan)을 분석하고 인덱스(Index)의 구조를 이해하는 것이 튜닝의 핵심입니다.

🚀 주요 튜닝 원칙 및 사례 연구¶

복합 인덱스를 구성할 때는 카디널리티가 높은(중복도가 낮은) 컬럼을 선두에 두어야 합니다.

Bad SQL: 성별(중복도 높음) + 성(중복도 낮음) 순서의 인덱스 사용

-- 인덱스: (성별, 성)
SELECT 사원번호, 이름 FROM 사원 WHERE 성별 = 'M' AND 성 = 'Baba';

Good SQL (Tuned): 카디널리티가 높은 '성' 컬럼을 선두로 인덱스 재구성
```
-- 최적의 인덱스: (성, 성별)
CREATE INDEX I_성_성별 ON 사원 (성, 성별);
```
- 이유: 선행 컬럼에서 데이터의 범위를 더 많이 좁힐수록 인덱스 스캔 효율이 극대화됩니다.

WHERE 절에서 인덱스 컬럼에 함수를 사용하거나 연산을 수행하면 인덱스를 타지 못하고 Full Table Scan이 발생합니다.

Bad SQL: 컬럼을 가공하여 비교

SELECT * FROM 주문 WHERE TO_CHAR(주문일자, 'YYYYMMDD') = '20240421';

Good SQL (Tuned): 비교 대상을 가공하여 컬럼의 원형 유지

SELECT * FROM 주문 WHERE 주문일자 >= TO_DATE('20240421', 'YYYYMMDD')
                     AND 주문일자 < TO_DATE('20240422', 'YYYYMMDD');

데이터 타입이 일치하지 않으면 데이터베이스가 내부적으로 형변환을 시도하며, 이 과정에서 인덱스가 무효화될 수 있습니다.

Bad SQL: 문자열 컬럼(사원번호)에 숫자 값을 전달

-- 사원번호가 VARCHAR(20)인 경우
SELECT * FROM 사원 WHERE 사원번호 = 10001;

Good SQL (Tuned): 정확한 데이터 타입으로 명시

SELECT * FROM 사원 WHERE 사원번호 = '10001';

SELECT * 지양: 필요한 컬럼만 명시하여 네트워크 부하와 메모리 사용량을 줄이세요.
EXISTS vs IN: 대량의 데이터를 체크할 때는 IN보다 EXISTS가 유리할 때가 많습니다. (반대 경우도 있으므로 실행 계획 확인 필수)
UNION ALL 권장: 중복 제거가 필요 없다면 비용이 큰 UNION 대신 UNION ALL을 사용하세요.
페이징 최적화: 큰 오프셋(OFFSET)은 성능을 저하시킵니다. Index Only Scan이나 No-offset 방식을 고려하세요.

상세한 튜닝 과정은 아래 개별 문서를 참고하세요.

본 가이드는 데이터베이스 엔지니어링 실습을 바탕으로 작성되었으며, 성능 최적화의 기본 원칙을 제시합니다.