결론
Query Cache는 단순히 읽기 캐시에 불과하며,
실제 운영 환경에서 오히려 병목을 초래했기 때문에 제거되었다.
MySQL 5.7까지는 query_cache_type, query_cache_size 설정으로 사용이 가능했지만,
MySQL 8.0부터는 완전히 코드 레벨에서 제거되어 더 이상 사용할 수 없게 되었다.
이러한 사례를 통해 Query Cache의 단점을 알 수 있을 것 같아 찾아보았다.
1. 병목 현상의 원인이 되었기 때문
Query Cache는 전체 테이블이 아닌, SQL 문자열 자체에 대해 캐시를 수행한다.
이 캐시는 테이블에 변경이 한 번이라도 발생하면 전체 캐시가 무효화되기 때문에,
쓰기 작업이 잦은 테이블일수록 캐시 조회율이 떨어지고,
매번 캐시를 비우고 다시 채워야 하는 락(lock) 비용이 크게 발생한다.
즉, 데이터 변경이 많은 OLTP 환경에서는 캐시의 효용성보다 락 경합(contention)으로 인한 성능 저하가 더 컸던 것이다.
2. 스레드 간 락 경합으로 멀티코어 환경에서 성능 저하
Query Cache는 글로벌 캐시로, 다수의 스레드가 동시에 접근하면 락이 걸린다.
이는 멀티코어 환경에서 병목을 유발하며, CPU 자원을 제대로 활용하지 못하는 결과를 낳았다.
3. 비결정적(non-deterministic) 동작으로 인해 예측 불가한 성능
캐시에 저장된 쿼리 결과는 완전히 동일한 SQL 문자열이 다시 실행될 때만 재사용된다.
쿼리의 공백, 주석 차이만 있어도 캐시를 재사용하지 못하며,
실제 운영에서는 기대만큼 일관된 성능 향상이 일어나지 않았다.
4. 대안 기술의 발전
InnoDB Buffer Pool, Redis 등 외부 캐시, Application-Level Cache, ORM 2차 캐시 등의 기술이 발전하면서 Query Cache의 필요성이 줄어들었다.
