8.9.3.1. Как Кэш Запроса Работает

Этот раздел описывает, как кэш запроса работает, когда это является операционным. Раздел 8.9.3.3, "Конфигурация Кэша Запроса", описывает, как управлять, является ли это операционным.

Входящие запросы по сравнению с теми в кэше запроса перед парсингом, таким образом, следующие два запроса расцениваются как отличающиеся кэшем запроса:

SELECT * FROM tbl_nameSelect * from tbl_name

Запросы должны быть точно тем же самым (байт для байта), чтобы быть замеченными как идентичные. Кроме того, запросите строки, которые идентичны, может быть обработан как отличающийся по другим причинам. Запросы, которые используют различные базы данных, различные версии протокола, или различные наборы символов значения по умолчанию, считают различными запросами и кэшируются отдельно.

Кэш не используется для запросов следующих типов:

Запросы, которые являются подзапросом внешнего запроса
Запросы, выполняемые в пределах тела сохраненной функции, триггера, или события

Прежде, чем результат запроса будет выбран от кэша запроса, проверки MySQL, имеет ли пользователь SELECT полномочие для всех баз данных и таблиц включается. Если дело обстоит не так, кэшируемый результат не используется.

Если результат запроса возвращается из кэша запроса, сервер постепенно увеличивается Qcache_hits переменная состояния, нет Com_select. См. Раздел 8.9.3.4, "Состояние Кэша запроса и Обслуживание".

Если таблица изменяется, все кэшируемые запросы, которые используют таблицу, становятся недопустимыми и удаляются из кэша. Это включает запросы то использование MERGE таблицы, которые отображаются на измененную таблицу. Таблица может быть изменена многими типами операторов, такой как INSERT, UPDATE, DELETE, TRUNCATE TABLE, ALTER TABLE, DROP TABLE, или DROP DATABASE.

Кэш запроса также работает в пределах транзакций при использовании InnoDB таблицы.

В MySQL 5.6, следствие a SELECT запрос на представлении кэшируется.

Кэш запроса работает на SELECT SQL_CALC_FOUND_ROWS ... запросы и хранилища значение, которое возвращается следующим SELECT FOUND_ROWS() запрос. FOUND_ROWS() возвращает корректное значение, даже если предыдущий запрос был выбран от кэша, потому что число найденных строк также сохранено в кэше. SELECT FOUND_ROWS() сам запрос не может кэшироваться.

Готовые заявления, которые делаются, используя использование протокола двоичной синхронной передачи данных mysql_stmt_prepare() и mysql_stmt_execute() (см. Раздел 22.8.8, "API C Готовые Операторы"), подвергаются ограничениям на кэширование. Сравнение с операторами в кэше запроса основано на тексте оператора после расширения ? маркеры параметра. Оператор сравнивается только с другими кэшируемыми операторами, которые выполнялись, используя протокол двоичной синхронной передачи данных. Таким образом, в целях кэша запроса вышли подготовленные операторы, использование протокола двоичной синхронной передачи данных отличны от готовых заявлений, сделанных, используя текстовый протокол (см. Раздел 13.5, "Синтаксис SQL для Готовых Операторов").

Запрос не может кэшироваться, если он содержит какую-либо из функций, показанных в следующей таблице.

`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()`
`RELEASE_LOCK()`	`SLEEP()`	`SYSDATE()`
`UNIX_TIMESTAMP()` без параметров	`USER()`	`UUID()`
`UUID_SHORT()`

Запрос также не кэшируется при этих условиях:

Это обращается к определяемым пользователем функциям (UDFs) или сохраненным функциям.
Это обращается к пользовательским переменным или локальным сохраненным переменным программы.
Это обращается к таблицам в mysql, INFORMATION_SCHEMA, или performance_schema база данных.
(MySQL 5.6.5 и позже:) Это ссылается на любые разделенные таблицы.
Это имеет любую из следующих форм:
```
SELECT ... LOCK IN SHARE MODESELECT ... FOR UPDATESELECT ... INTO OUTFILE ...SELECT ... INTO DUMPFILE ...SELECT * FROM ... WHERE autoincrement_col IS NULL
```
Последняя форма не кэшируется, потому что она используется в качестве обходного решения ODBC для того, чтобы получить последнее Значение идентификатора вставки. См. раздел Соединителя/ODBC Главы 22, Соединителей и API.

Операторы в пределах транзакций то использование SERIALIZABLE уровень изоляции также не может кэшироваться, потому что они используют LOCK IN SHARE MODE блокировка.
Это использует TEMPORARY таблицы.
Это не использует таблиц.
Это генерирует предупреждения.
У пользователя есть полномочие на уровне столбца для любой из включенных таблиц.