[MySQL] (환경설정4️⃣) query_cache는 아직 유효한가? 설정 전략 분석

MySQL의 query_cache는 같은 쿼리를 반복 실행할 때 결과를 메모리에 저장해 속도를 대폭 향상시키는 기능이었다.
하지만 최근에는 이 기능이 오히려 병목을 유발하는 사례가 많아, MySQL 8.0에서는 아예 제거되었다.

🧠 query_cache란?

• 쿼리 결과를 캐싱해 같은 쿼리가 들어오면 재실행 없이 결과만 반환
• 읽기 위주의 환경에서는 매우 유용
• 하지만 데이터 변경이 자주 일어나는 환경에서는 캐시 무효화로 인한 성능 저하 발생

🧪 기본 동작 방식

1. 클라이언트가 동일한 SELECT 쿼리를 보냄
2. query_cache에 동일 쿼리 결과가 있으면 결과만 반환
3. INSERT/UPDATE/DELETE 발생 시 관련 테이블의 캐시 무효화 발생

즉, 쓰기 작업이 많을수록 비효율이 된다.

반응형

🔍 관련 설정 항목

항목	설명
query_cache_type	쿼리 캐시 사용 여부 (0: 끔, 1: 사용, 2: SELECT SQL_CACHE만)
query_cache_size	전체 캐시 메모리 크기 (MB 단위)
query_cache_limit	쿼리당 최대 캐시 크기
query_cache_min_res_unit	캐시 메모리의 최소 단위 블록 크기

예시 설정 (my.cnf):

query_cache_type = 1
query_cache_size = 64M
query_cache_limit = 1M

📊 실무 환경 체크 포인트

✅ 현재 캐시 설정 확인

SHOW VARIABLES LIKE 'query_cache%';

✅ 캐시 사용량과 비율 확인

SHOW STATUS LIKE 'Qcache%';

중요 지표:

• Qcache_hits: 캐시가 사용된 횟수
• Qcache_inserts: 새로 캐시에 저장된 횟수
• Qcache_lowmem_prunes: 캐시 부족으로 삭제된 횟수
  → 이 값이 계속 증가하면 캐시 사이즈 부족

✅ 캐시 적중률 계산

Hit Ratio = Qcache_hits / (Qcache_hits + Qcache_inserts)

50% 이상이 아니면 query_cache는 성능 개선 효과가 거의 없다.

반응형

🔥 비활성화 권장 조건

• 쓰기 트래픽이 많은 OLTP 시스템
• INSERT/UPDATE가 자주 일어나는 게시판, 거래시스템, 로그성 테이블
• MySQL 5.7 이상에서 InnoDB + Buffer Pool 중심 아키텍처를 사용하는 경우

✅ 활성화 추천 조건

• 정적인 조회가 많은 리포팅 서버
• 데이터 변경이 거의 없는 읽기 전용 레포트 뷰어
• 같은 SELECT 쿼리가 반복적으로 사용되는 API 서버

❌ query_cache 제거된 이유 (MySQL 8.0)

• 멀티스레드 환경에서 락 경합 심함
• 캐시 삭제 연산이 잦고 병목 발생
• 실제 사용자는 튜닝 어려움

→ MySQL 8.0부터는 아예 query_cache 기능 제거됨

🧠 실무 팁

• 캐시를 쓰는 대신 쿼리 성능 향상을 위해 적절한 인덱싱과 Buffer Pool 활용이 우선
• 캐시는 성능 문제를 ‘숨기는’ 기능일 수 있다
• 정적인 데이터라면 Redis, Memcached 같은 애플리케이션 레벨 캐시를 고려하는 것이 더 나은 선택

✅ 정리

• query_cache는 과거에는 유용했지만, 지금은 비추천되는 설정이다.
• 읽기 전용 서버에서만 제한적으로 효과가 있으며, 쓰기 성능을 저하시킬 수 있다.
• MySQL 8.0 이후에는 이 기능이 완전히 제거되었다.
• 실무에서는 대부분 OFF 상태가 기본이며, 인덱스 및 버퍼 기반 튜닝이 우선이다.

🔗 공식 문서 참고
MySQL 5.7 Reference Manual – Query Cache Configuration