MySQL5.6 쿼리 캐시 동작

8.9.3.1 쿼리 캐시 동작

이 섹션에서는 쿼리 캐시가 작동 가능한 경우 그 방법에 대해 설명합니다. 섹션 8.9.3.3 "쿼리 캐시 구성" 에서는 그것을 작동 할 수 있는지 여부를 제어하는 방법을 설명하고 있습니다.

받은 쿼리는 분석 전에 쿼리 캐시에있는 그들과 비교되기 때문에 다음 두 쿼리는 쿼리 캐시에 의해 다른 것으로 간주됩니다.

 SELECT * FROM tbl_name Select * from tbl_name

쿼리는 동일한 것으로 간주되기 위해서는 똑같은 (바이트 단위)이어야합니다. 또한 다른 이유로 동일한 쿼리 문자열이 다른 것으로 간주 될 수 있습니다. 다른 데이터베이스, 서로 다른 프로토콜 버전 또는 다른 기본 문자 집합을 사용하는 쿼리는 다른 쿼리로 간주되며 별도로 캐시됩니다.

다음과 같은 유형의 쿼리는 캐시가 사용되지 않습니다.

외부 쿼리의 하위 쿼리 인 쿼리
스토어드 함수, 트리거 또는 이벤트의 본체 내에서 실행되는 쿼리

쿼리 결과를 쿼리 캐시에서 가져 오기 전에 MySQL은 관련된 모든 데이터베이스와 테이블에 사용자가 SELECT 권한을 가지고 있는지 확인합니다. 이것이 맞지 않는 경우, 캐시 결과는 사용되지 않습니다.

쿼리 결과가 쿼리 캐시에서 반환되는 경우, 서버는 Com_select 아닌 Qcache_hits 상태 변수를 증가시킵니다. 섹션 8.9.3.4 "쿼리 캐시의 상태 및 유지 보수" 를 참조하십시오.

테이블이 변경된 경우 해당 테이블을 사용하는 캐시 된 모든 쿼리가 비활성화 캐시에서 삭제됩니다. 여기에는 변경된 테이블에 매핑 된 MERGE 테이블을 사용하는 쿼리도 포함됩니다. 테이블은 INSERT , UPDATE , DELETE , TRUNCATE TABLE , ALTER TABLE , DROP TABLE 또는 DROP DATABASE 등 많은 종류의 문으로 변경할 수 있습니다.

InnoDB 테이블을 사용할 때 트랜잭션 내에서 쿼리 캐시 기능합니다.

MySQL 5.6는 뷰의 SELECT 쿼리의 결과가 캐시됩니다.

쿼리 캐시는 SELECT SQL_CALC_FOUND_ROWS ... 쿼리에 대해 작동 후속 SELECT FOUND_ROWS() 쿼리에서 반환 된 값을 저장합니다. FOUND_ROWS() 는 이전 쿼리가 캐시에서 가져온 경우에도 발견 된 행의 수를 캐시에 저장되어 있기 때문에 정확한 값을 반환합니다. SELECT FOUND_ROWS() 쿼리 자체는 캐시 할 수 없습니다.

mysql_stmt_prepare() 및 mysql_stmt_execute() 를 사용하여 바이너리 프로토콜을 사용하여 발행 된 준비된 문 ( 섹션 23.8.8 "C API 준비된 문" 을 참조하십시오)은 캐시가 제한됩니다. 쿼리 캐시의 문과의 비교는 ? 파라미터 마커의 확장 된 명령의 텍스트를 기반으로합니다. 문은 바이너리 프로토콜을 사용하여 수행 된 다른 캐시 된 문에만 비교됩니다. 즉, 쿼리 캐시의 목적으로 바이너리 프로토콜을 사용하여 발행 된 준비된 명령문은 텍스트 프로토콜을 사용하여 발행 된 준비된 문 ( 섹션 13.5 "준비된 문을위한 SQL 구문" 을 참조하십시오 )로 구분됩니다.

쿼리에 다음 표에 나열된 함수 중 하나가 포함 된 경우 쿼리 캐시 할 수 없습니다.

`AES_DECRYPT()` (5.7.4 현재)	`AES_ENCRYPT()` (5.7.4 현재)	`BENCHMARK()`
`CONNECTION_ID()`	`CONVERT_TZ()`	`CURDATE()`
`CURRENT_DATE()`	`CURRENT_TIME()`	`CURRENT_TIMESTAMP()`
`CURTIME()`	`DATABASE()`	하나의 파라미터를 가지는 `ENCRYPT()`
`FOUND_ROWS()`	`GET_LOCK()`	`LAST_INSERT_ID()`
`LOAD_FILE()`	`MASTER_POS_WAIT()`	`NOW()`
`PASSWORD()`	`RAND()`	`RANDOM_BYTES()`
`RELEASE_LOCK()`	`SLEEP()`	`SYSDATE()`
매개 변수가없는 `UNIX_TIMESTAMP()`	`USER()`	`UUID()`
`UUID_SHORT()`

다음과 같은 조건의 쿼리도 캐시되지 않습니다.

그것이 사용자 정의 함수 (UDF) 또는 스토어드 함수를 참조하고있다.
그것이 사용자 변수 또는 로컬에 저장된 프로그램 변수를 참조하고있다.
그것이 mysql , INFORMATION_SCHEMA 또는 performance_schema 데이터베이스의 테이블을 참조하고있다.
(MySQL 5.6.5 이후 :) 그것은 분할 된 테이블을 참조하고있다.
그것은 다음과 같은 형식이다.
```
 SELECT ... LOCK IN SHARE MODE
 SELECT ... FOR UPDATE
 SELECT ... INTO OUTFILE ...
 SELECT ... INTO DUMPFILE ...
 SELECT * FROM ... WHERE autoincrement_col IS NULL
```
마지막 형식은 마지막 삽입 ID 값을 취득하기위한 ODBC의 해결 방법으로 사용되기 때문에 캐시되지 않습니다. 제 23 장 "Connector 및 API ' 의 Connector / ODBC 섹션을 참조하십시오.

SERIALIZABLE 격리 수준을 사용하는 트랜잭션의 문은 LOCK IN SHARE MODE 잠금을 사용하기 때문에 그들도 캐시 할 수 없습니다.
그것이 TEMPORARY 테이블을 사용하고있다.
그것이 어떤 테이블도 사용하지 않는다.
그것이 경고를 생성한다.
사용자가 관련된 모든 테이블의 컬럼 레벨의 권한을 가지고있다.