우리는 MySQL 5.6으로 업그레이드하고 db 서버의 로딩이 크게 증가하는 것을보기 시작했으며 마침내 query_cache_type5.6에서 기본값이 off start로 나타났습니다 .

우리는 그것을 다시 활성화했고 로딩이 감소하는 것을 보았습니다. 왜 MySQL 5.6부터이 값이 기본적으로 비활성화되어 있습니까? 문제를 해결할 수 없습니다.

이유를 이해하려면 InnoDB의 역사가 필요합니다. 여기 간다:

전쟁 이야기

InnoDB와 쿼리 캐시는 일정한 전쟁 상태에 있습니다. InnoDB 버퍼 풀의 변경 사항을 검사 한 다음 동일한 변경 사항에 대해 쿼리 캐시를 교차 검사 할 때 InnoDB는 매우 큰 손이됩니다.

평화 조약

MySQL 5.0 이전에는 InnoDB에 대해 쿼리 캐시가 비활성화되었습니다. 이제 InnoDB와 상호 작용합니다. 문제를 단순화하기 위해 query_cache_size 를 0 으로 설정하여 쿼리 캐시를 비활성화 할 수 있습니다 .

query_cache_time 의 MySQL 문서에 따르면

query_cache_type 을 0으로 설정 하여 서버를 시작 하면 쿼리 캐시 뮤텍스를 전혀 얻지 못하므로 런타임에 쿼리 캐시를 사용할 수 없으며 쿼리 실행시 오버 헤드가 줄어 듭니다.

서린 터 약관

query_cache_size 를 0으로 설정 하는 것은 모든 것이 적합한 솔루션이 아닙니다.

전쟁의 이유는 우선 오버 헤드입니다. InnoDB는 항상 변경 사항을 검사합니다. 쿼리 캐시가 클수록 InnoDB의 작동이 훨씬 어려워집니다. 쿼리 캐시를 비활성화하면 InnoDB와 쿼리 캐시가 행복해집니다. 그러나 귀하 (개발자 / DBA)는 그러한 평화 조약을 마련하더라도 쿼리 성능이 저하되어 전쟁의 희생자 일 수 있습니다.

다음에 따라

• 작업량
• 변경 빈도
• 동일한 데이터를 읽는 빈도

query_cache_size 를 성능을 높이는 것으로 느끼는 숫자로 설정해야 합니다 (지하 이동 시작과 가장 유사 함).

발문

이 전쟁 이야기를 어디서 생각해 냈는지 궁금하다면 이전 게시물을 참조하십시오

• Sep 05, 2012: 자주 쿼리 캐시 무효화의 오버 헤드가 가치가 있습니까?

고성능 MySQL (2 판)의 209-215 페이지 에서이 내용을 배웠으므로주의 깊게 읽으십시오.

전에 다른 사람들에게 쿼리 캐시를 비활성화하는 것이 좋습니다.

• Sep 25, 2013: 쿼리 캐시 항목 무효화 (키)
• Sep 26, 2013: 쿼리 캐시 적중 값이 데이터베이스에서 변경되지 않습니다
• Dec 23, 2013: CPU 및 메모리 사용량이 높은 MySQL

참고 : 질문은 query_cache_type 에 관한 것 입니다. 쿼리 캐시에 영향을 미칩니다. 캐시를 비활성화하면 InnoDB가 캐시를 지배하게됩니다. query_cache_type을 수동으로 설정하면 개발자 / DBA가 쿼리 캐시에서 발생하는 쿼리 유형에 대해 신중하게 생각하게됩니다.

왜 이것이 여기에 있는지 설명 하는 블로그 게시물 이 있습니다 .

짧은 버전 : 쿼리 캐시로 인해 멀티 코어 시스템에서 확장 성 문제가 발생합니다. 이제 기본적으로 비활성화되어 있습니다.

답변을 완성하기 위해 오라클은 쿼리 캐시 기능을 "대체"하는 것이 memcached 통합 입니다.