쿼리 최적화와 성능

🔄 Quick Recall: 이전 레슨에서 AI로 지저분한 데이터를 클리닝했어요 — 프로파일링, 표준화, 중복 제거, 검증. 이번에는 그 깨끗한 데이터에서 실행되는 쿼리가 빠른지 확인해요.

쿼리가 느려질 때

느린 쿼리는 보통 스스로를 알려요: 30초 걸리는 대시보드, 타임아웃되는 리포트, 사용자를 기다리게 하는 API. 원인은 데이터베이스 자체가 거의 아니에요 — 거의 항상 쿼리나 빠진 인덱스예요.

AI는 실행 계획을 읽고 사람이 몇 년의 경험이 필요한 패턴을 잡아내기 때문에 최적화에 뛰어나요.

AI로 실행 계획 읽기

EXPLAIN ANALYZE는 진단 도구예요. 느린 쿼리에 실행하고 그 출력을 AI에 붙여넣으세요. AI에게 물어볼 것: 가장 큰 성능 병목은? 불필요한 순차 스캔이 있나? 행 추정이 정확한가 아니면 크게 벗어나는가? 어떤 인덱스가 도움이 되나? 더 빠르게 재작성할 수 있나?

✅ Quick Check: 실행 계획에서 데이터베이스의 행 추정이 “크게 벗어나면” 왜 중요할까요? 쿼리 플래너가 추정 행 수에 기반해 전략을 선택하기 때문이에요. 100행으로 추정했는데 실제가 100,000이면 중첩 루프 조인(작은 집합에 효율적)을 선택할 수 있는데, 해시 조인(큰 집합에 효율적)이 극적으로 빠를 수 있어요. 부정확한 추정은 보통 테이블 통계가 오래됐다는 뜻이에요 — ANALYZE를 실행하면 해결돼요.

전략적 인덱싱

모든 인덱스가 동등하지 않아요:

복합 인덱스: 등호 칼럼을 먼저, 범위 칼럼을 뒤에. (customer_id, order_date)가 (order_date, customer_id)보다 고객별 주문 조회에 효과적.

부분 인덱스: 보류 중인 주문만 쿼리하면, CREATE INDEX ON orders (created_at) WHERE status = 'pending'이 모든 상태를 인덱싱하는 것보다 작고 빨라요.

과다 인덱싱 금지: 인덱스마다 INSERT/UPDATE를 느리게 해요. 초당 10,000 쓰기가 있는 테이블에 인덱스 5개를 추가하면 심각한 오버헤드가 생겨요.

일반적인 최적화 패턴

*SELECT 를 구체적 칼럼으로 교체:

-- 느림 (모든 칼럼을 디스크에서 읽기)
SELECT * FROM orders WHERE customer_id = 123;
-- 빠름 (필요한 칼럼만, 커버링 인덱스 사용 가능)
SELECT id, total, order_date FROM orders WHERE customer_id = 123;

HAVING에서 WHERE로 필터 이동:

-- 느림 (모든 행 그룹화 후 필터)
SELECT customer_id, SUM(total) FROM orders
GROUP BY customer_id HAVING customer_id IN (1, 2, 3);
-- 빠름 (먼저 필터, 적은 행 그룹화)
SELECT customer_id, SUM(total) FROM orders
WHERE customer_id IN (1, 2, 3) GROUP BY customer_id;

서브쿼리에 IN 대신 EXISTS:

-- 서브쿼리 결과가 클 때 느림
SELECT * FROM customers WHERE id IN (SELECT customer_id FROM orders);
-- 빠름 (행당 첫 매치에서 멈춤)
SELECT * FROM customers c WHERE EXISTS (
    SELECT 1 FROM orders o WHERE o.customer_id = c.id
);

✅ Quick Check: 서브쿼리가 많은 행을 반환할 때 EXISTS가 IN보다 빠른 이유는? IN은 전체 서브쿼리 결과(수백만 값)를 구체화하고 외부 행마다 확인해요. EXISTS는 첫 매치에서 멈춰요 — 고객의 주문이 하나라도 있으면 다음으로 넘어가요.

핵심 정리

• EXPLAIN ANALYZE가 진단 도구 — 실행 계획을 AI에 붙여넣으면 즉석 전문가 수준 분석
• 전략적 인덱싱은 쿼리 패턴, 칼럼 카디널리티, 쓰기 오버헤드를 고려 — 모든 칼럼에 인덱스가 필요하진 않아요
• 복합 인덱스는 쿼리 패턴과 일치해야: 등호 칼럼 먼저, 범위 칼럼 뒤에
• 빠른 개선: SELECT * 교체, WHERE로 필터 이동, 큰 서브쿼리에 IN 대신 EXISTS
• 오래된 테이블 통계는 플래너가 잘못된 전략을 선택하게 해요 — 정기적으로 ANALYZE 실행
• 지속적 모니터링이 느린 쿼리를 사용자 불만 전에 잡아요

Up next: 다음 레슨에서 AI로 리포트와 대시보드를 구축해요 — 최적화된 쿼리를 이해관계자가 실제로 쓰는 비즈니스 인텔리전스로 변환.