🎯 학습 목표
- SQL 튜닝의 목적(응답시간 vs 처리량)을 구분한다.
- “느린 SQL을 만났을 때 무엇부터 보는가”라는 접근 순서를 세운다.
- 일량(I/O)을 줄이는 것이 튜닝의 본질임을 이해한다.
📖 튜닝은 “일량을 줄이는 일”이다
데이터베이스가 느린 가장 흔한 이유는 읽지 않아도 될 데이터를 너무 많이 읽기 때문입니다. 100만 건 테이블에서 10건을 찾는데 100만 건을 모두 훑는다면, CPU가 빨라도 디스크/메모리에서 블록을 읽어오는 일량 자체가 많아 느립니다. SQL 튜닝의 본질은 같은 결과를 더 적은 블록 I/O로 얻도록 실행 방법을 바꾸는 것입니다.
그래서 튜닝의 핵심 지표는 “코드 줄 수”나 “쿼리 길이”가 아니라 읽은 블록 수(logical reads / consistent gets)입니다. 같은 SQL이라도 인덱스를 타느냐 전체 스캔을 하느냐에 따라 읽는 블록이 수천 배 차이 납니다.
📖 두 가지 목표: 응답시간과 처리량
- 응답시간(Response Time): 사용자가 결과 한 건(또는 첫 화면)을 받기까지 걸리는 시간. OLTP(주문, 조회 화면)에서 중요. → “빨리 첫 결과를 보여줘라” = 부분범위 처리가 유리.
- 처리량(Throughput): 단위 시간당 처리하는 전체 데이터 양. 배치/집계에서 중요. → “전체를 가장 적은 일량으로 끝내라” = 전체 스캔 + 해시 조인이 유리할 때가 많음.
두 목표는 종종 충돌합니다. “첫 10건만 빨리”가 목표면 인덱스가 유리하고, “1억 건 전부 집계”가 목표면 인덱스보다 전체 스캔이 더 빠릅니다. 튜닝 전에 “이 SQL의 목표가 무엇인가”를 먼저 정해야 올바른 방향을 잡습니다.
📖 느린 SQL을 만났을 때의 접근 순서
1) 무엇이 느린가? — 어떤 SQL이, 얼마나, 언제 느린지 사실부터 확인
2) 실행계획을 본다 — 옵티마이저가 실제로 어떻게 실행하는지 (2강)
3) 일량을 본다 — 읽은 블록 수(logical reads)가 결과 건수에 비해 과한가?
4) 원인을 좁힌다 — 인덱스 미사용? 잘못된 조인? 통계 부정확?
5) 한 번에 하나만 바꾼다 — 바꾸고 → 다시 측정 → 효과 확인 (추측 금지)핵심은 “추측하지 말고 측정하라”입니다. “이 SQL이 느린 것 같다”가 아니라, 실행계획과 읽은 블록 수라는 숫자로 판단합니다.
💻 같은 결과, 다른 일량 (개념 예시)
-- 회원 1000만 건 테이블에서 이메일로 1명 찾기
SELECT * FROM members WHERE email = 'kim@example.com';
-- email에 인덱스가 없으면: Full Table Scan → 1000만 건 모두 읽음 (수만 블록)
-- email에 인덱스가 있으면: Index Range Scan → 몇 블록만 읽고 1건 반환
-- 결과는 똑같지만 일량은 수천 배 차이⚠️ 주의사항
- “인덱스를 무조건 많이 만들면 빠르다”는 오해입니다. 인덱스는 조회를 빠르게 하지만 INSERT/UPDATE/DELETE를 느리게 하고 저장공간을 씁니다(3강에서 자세히).
- 장비(CPU/메모리) 증설로 해결하려 하기 전에, 먼저 SQL이 읽는 일량 자체를 줄일 수 있는지를 봅니다. 잘못된 SQL은 장비를 키워도 비효율이 그대로 커집니다.
💡 팁
- 튜닝의 80%는 “인덱스를 제대로 타게 만드는 것”과 “조인 순서/방식을 바로잡는 것”에서 나옵니다. 이 강좌는 그 두 축을 중심으로 진행합니다.
- 다음 강(2강)에서 실제로 옵티마이저가 어떻게 실행하는지 보는 법(실행계획)을 배웁니다. 모든 튜닝은 여기서 시작합니다.