Retiring Support for the Query Cache

오래전에 올라온 글이기는 하지만, 한번 쯤 정리하고 가도 좋겠다 싶어서 이전에 나온 글을 간단히 정리해 보도록 한다. 

참고글 : 

https://mysqlserverteam.com/mysql-8-0-retiring-support-for-the-query-cache/

MySQL 8.0: Retiring Support for the Query Cache - MySQL Server Blog

 

해당 글에는 Query Cache가 특정 상황에서 좋은 성능을 보여주었음에도 불구하고, MySQL Ver. 8.0부터 더 이상 그 기능을 버리고 가게 되었는지 간단히 정리하고 있다. 

필자도 5.6까지 특정 케이스에 대해 활성화하여 사용하기는 했지만, 말그대로 특정 케이스에 대해서만 그 성능을 보여주는 기능이었다. 이 기능을 기본적으로 켜고 가면 다수의 oltp 상황에서 더 낮은 성능을 보여주는 기능이었다. 이것으느 Query Cache의 한계를 보여주기도 하는데, Query Cache는 기본적으로 작성된 쿼리 및 결과가 한치에 오차도 없이 Byte 단위까지 모두 맞아야지만 그 기능을 온전히 사용할 수 있기 때문이다. 또한, 테이블에 DML이 발생하면 캐쉬된 결과값은 바로 disable되기 때문에 OLTP성 서비스인 경우 그 기능을 온전히 사용할 수도 없었다. 그래서 Query Cache의 한계및 단점에 해당하지 않는 테이블 및 쿼리에 대해서만 사용이 가능하다는 기능적 한계를 가지고 있었다. 

 

그래서 그런지 이 기능에 문제가 있다고 여러 사람이 노티한 글들이 많다고 저 글의 필자도 이야기 하고 있다. 

The query cache has been disabled-by-default since MySQL 5.6 (2013) as it is known to not scale with high-throughput workloads on multi-core machines. Rene confirmed this in his post yesterday, but it has also previously been mentioned by Stewart Smith, Domas Mituzas (update: and Kristian Koehntopp).

We concur with the research performed by Jiamin Huang, Barzan Mozafari, Grant Schoenebeck, Thomas F. Wenisch at the University of Michigan, Ann Arbor.  We considered what improvements we could make to query cache versus optimizations that we could make which provide improvements to all workloads.

 

그래서 결국은 전반적인 MySQL의 성능 향상에 리소스를 쓰기로 결정하고, 해당 기능은 버리기로 전략을 바꿨다고 말하고 있다. 

While these choices themselves are orthogonal, engineering resources are finite.  That is to say that we are shifting strategy to invest in improvements that are more generally applicable to all workloads.

그럼 특정 쿼리의 실행 속도 향상은 어떻게 할 수 있는가? 해당 블로그 글의 필자는 ProxySQL을 사용하라고 권장한다. 

MySQL 8.0 will not support query cache, and users upgrading will be encouraged to use either Server-side Query Rewrite or ProxySQL as a man-in-the-middle cache.

필요하다면 ProxySQL도 공부해 봐야 겠다.