8.10.3.1 How the Query Cache Operates — MySQL 5.7

8.10.3.1 Как работает кэш запросов

Примечание

Кэш запросов устарел начиная с MySQL 5.7.20 и удален в MySQL 8.0.

В этом разделе описано, как работает кэш запросов, когда он активен. Раздел 8.10.3.3, «Настройка кэша запросов» описывает, как управлять его активностью.

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

SELECT * FROM tbl_name
Select * from tbl_name

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

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

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

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

Если результат запроса возвращается из кэша запросов, сервер увеличивает переменную состояния Qcache_hits, а не Com_select. См. Раздел 8.10.3.4, «Статус и обслуживание кэша запросов».

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

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

Результат запроса SELECT на представлении кэшируется.

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

Подготовленные операторы, выполняемые с использованием двоичного протокола, ограничены в возможностях кэширования. Сравнение с операторами в кэше запросов основано на тексте оператора после расширения ? маркеров параметров. Оператор сравнивается только с другими кэшированными операторами, которые выполнялись с использованием двоичного протокола. То есть для целей кэша запросов подготовленные операторы, выполняемые с использованием двоичного протокола, отличаются от подготовленных операторов, выполняемых с использованием текстового протокола (см. Раздел 13.5, «Подготовленные операторы»).

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

END_OF_DOCUMENT_MARKER

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

Он ссылается на загружаемые функции или сохраненные функции.
Он ссылается на переменные пользователя или локальные переменные сохраненной программы.
Он ссылается на таблицы в базе данных mysql, INFORMATION_SCHEMA или performance_schema.
Он ссылается на любые разграниченные таблицы.
Он имеет один из следующих форматов:
```
SELECT ... LOCK IN SHARE MODE
SELECT ... FOR UPDATE
SELECT ... INTO OUTFILE ...
SELECT ... INTO DUMPFILE ...
SELECT * FROM ... WHERE autoincrement_col IS NULL
```
Последняя форма не кэшируется, так как используется как обходной путь ODBC для получения значения последнего вставленного идентификатора. См. раздел Connector/ODBC в главе 27, Подключаемые модули и API.

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