8.9.3 MySQL 쿼리 캐시
쿼리 캐시는 클라이언트로 전송 된 해당 결과와 함께 SELECT 문 텍스트가 포함됩니다. 나중에 같은 문을 받았을 경우, 서버는 그 문을 다시 해석하고 실행하는 대신에 쿼리 캐시에서 결과를 가져옵니다. 쿼리 캐시는 세션간에 공유되므로 하나의 클라이언트에서 생성 된 결과 집합을 다른 클라이언트에 의해 발행 된 같은 쿼리에 대한 응답으로 보낼 수 있습니다.
쿼리 캐시는 자주 수정되지 않는 테이블이 있고 그에 대해 서버가 많은 동일한 질의를받는 환경에서 유용 할 수 있습니다. 이것은 데이터베이스의 내용에 따라 많은 동적 페이지를 생성하는 많은 Web 서버에 일반적인 상황입니다.
쿼리 캐시는 오래된 데이터를 반환하지 않습니다. 테이블이 변경되면 쿼리 캐시 관련 항목이 플래시됩니다.
같은 MyISAM 테이블을 업데이트하는 복수의 mysqld 서버가있는 환경에서는 쿼리 캐시가 작동하지 않습니다.
쿼리 캐시는 섹션 8.9.3.1 "쿼리 캐시 동작" 에 설명 된 조건에서 준비된 문에 사용됩니다.
MySQL 5.6.5 현재 쿼리 캐시는 파티션 된 테이블에 대해서는 지원되지 않고 분할 된 테이블을 포함하는 쿼리는 자동으로 비활성화됩니다. 그런 쿼리에 대해 쿼리 캐시를 사용할 수 없습니다. (Bug # 53775)
쿼리 캐시의 일부 성능 데이터를 보여줍니다. 이러한 결과는 2G 바이트의 RAM과 64M 바이트의 쿼리 캐시를 탑재하는 Linux Alpha 2 × 500MHz 시스템에서 MySQL 벤치 마크 스위트를 실행하여 생성되었습니다.
실행중인 모든 쿼리는 간단하다 (1 행의 테이블에서 행을 선택하는 등)이 여전히 다르기 때문에 쿼리를 캐시 할 수없는 경우 쿼리 캐시를 활성화 해두기위한 오버 헤드는 13 %입니다 . 이것은 최악의 시나리오로 간주 될 수 있습니다. 사실, 쿼리는 훨씬 더 복잡 해지는 경향이 있기 때문에 오버 헤드는 일반적으로 매우 낮습니다.
단일 행 테이블의 단일 행의 검색 쿼리 캐시가 있는데, 그것은이없는 경우보다 238 % 빨라집니다. 이것은 캐시 된 쿼리에 예상되는 최소 속도에 가까운 것으로 간주 할 수 있습니다.
서버가 시작될 때 쿼리 캐시를 비활성화하려면 query_cache_size 시스템 변수를 0으로 설정합니다. 쿼리 캐시 코드를 해제하여 눈에 띄는 오버 헤드는 없습니다.
쿼리 캐시는 상당한 성능 향상의 가능성을 제공하지만 모든 환경에서 그렇게 될 것으로 가정하지 마십시오. 쿼리 캐시의 조직과 서버의 워크로드에 따라 실제 성능이 저하 될 수 있습니다.
쿼리 캐시의 크기를 지나치게 크게하면 캐시의 유지 보수에 필요한 오버 헤드가 그것을 사용하는 이유에 클 수 있습니다. 수십 메가 바이트의 크기가 일반적으로 유용합니다. 수백 메가 바이트의 크기는 그렇지 않을 수 있습니다.
서버의 워크로드는 쿼리 캐시의 효율성에 상당한 영향을 미칩니다. 거의 전체가 고정
SELECT문 세트로 구성된 복합 쿼리는 빈번한INSERT문에 의해 캐시의 결과가 지속적으로 해제되는 같은 복합 쿼리보다 캐시를 사용함으로써 혜택을 얻을 가능성이 훨씬 높아집니다. 경우에 따라 해결 방법으로SQL_NO_CACHE옵션을 사용하여 자주 변경되는 테이블을 사용하는SELECT문에 대한 결과를 캐시에 넣지 않도록합니다. ( 섹션 8.9.3.2 "쿼리 캐시 SELECT 옵션" 을 참조하십시오.)
쿼리 캐시를 사용함으로써 혜택이 있는지 여부를 확인하려면 캐시를 활성화 및 비활성화하고 MySQL 서버의 작동을 테스트합니다. 서버의 워크로드가 변경되면 쿼리 캐시의 효율성도 바뀔 수 있기 때문에 이후 정기적으로 다시 테스트합니다.