[MySQL] 실행계획 캐시와 쿼리 플랜 재사용 이해하기 🚀

MySQL에서 쿼리를 실행할 때는 항상 테이블에서 데이터를 읽는 것이 전부가 아니다. MySQL Optimizer는 먼저 실행계획(Execution Plan)을 세운다. 이 실행계획을 캐시하고 재사용하는 쿼리 플랜 캐시(Query Plan Cache) 메커니즘을 이해하면, 더 빠르고 안정적인 쿼리 성능을 낼 수 있다.

🧠 실행계획이란?

실행계획은 Optimizer가 어떤 인덱스를 사용할지, 조인의 순서, 정렬 방식 등을 결정한 전략이다. EXPLAIN 명령으로 확인할 수 있다.

예시:

EXPLAIN SELECT * FROM users WHERE email = 'abc@example.com';

이 실행계획이 자주 반복되는 쿼리에 대해 재사용된다면, 성능은 향상된다.

반응형

🗂️ 실행계획 캐시란?

MySQL은 Prepared Statement 또는 서버 내부에서 처리되는 쿼리에 대해 실행계획을 캐시할 수 있다. 이로 인해 동일한 쿼리가 여러 번 실행될 경우, Optimizer가 다시 계획을 수립할 필요 없이 기존 실행계획을 재사용한다.

✅ 캐시가 적용되는 예

PREPARE stmt FROM 'SELECT * FROM users WHERE email = ?';
EXECUTE stmt USING 'abc@example.com';

• 이 경우 실행계획이 한번 생성된 후 재사용됨

⚠️ 실행계획이 캐시되지 않는 경우

다음과 같은 조건에서는 실행계획이 매번 새로 생성될 수 있다:

• 리터럴 값이 매번 달라지는 일반 쿼리→ 이건 매번 새로 파싱됨

SELECT * FROM users WHERE email = 'abc@example.com';
SELECT * FROM users WHERE email = 'xyz@example.com';

• 테이블 통계 변경 (ANALYZE TABLE 등)
• 다이내믹 SQL
• 쿼리 구조 변경

🔄 실행계획 강제 재계산 트리거

MySQL은 내부적으로 다음과 같은 변화가 있을 경우 기존 실행계획을 무효화하고 새로 생성한다:

• ANALYZE TABLE
• 테이블 구조 변경
• 인덱스 추가/삭제
• 테이블 내 데이터 분포 심각하게 변경

🧪 실행계획 재사용 확인 실습

PREPARE stmt FROM 'SELECT * FROM orders WHERE order_date > ?';
EXECUTE stmt USING @from_date;

이 방식은 서버가 파싱 → 최적화 → 캐싱 → 실행이라는 단계 중 최적화(쿼리 플랜 수립)를 건너뛰고 캐시된 계획을 그대로 사용하게 한다.

📉 실행계획 캐시를 안 쓰면 생기는 문제

• 매 쿼리마다 옵티마이저가 동작하여 CPU 자원 소모
• 반복 쿼리 성능 저하
• 느려진 응답 시간
• 쿼리 튜닝 효과 감소

반응형

🧩 쿼리 캐시 vs 실행계획 캐시 차이

항목	쿼리 캐시	실행계획 캐시
역할	쿼리 결과를 저장	실행 방법을 저장
결과 재사용	완전히 동일한 쿼리만 가능	Prepared Statement 등에서 재사용
MySQL 8.0	제거됨	유지됨
속도 향상	캐시된 결과 반환	쿼리 최적화 생략

 

🔧 성능 최적화를 위한 팁

• Prepared Statement 적극 활용
• 파라미터 바인딩 방식으로 쿼리 구성
• 동일 쿼리는 구조를 유지하고 값만 다르게
• ANALYZE TABLE은 신중하게 사용

📎 참고 공식문서

• MySQL Prepared Statements
• MySQL Optimizer Overview