8.10.4 Caching of Prepared Statements and Stored Programs — MySQL 5.7

8.10.4 Кэширование подготовленных запросов и хранимых программ

Для определенных запросов, которые клиент может выполнять несколько раз во время сессии, сервер преобразует запрос во внутреннюю структуру и кэширует эту структуру для использования во время выполнения. Кэширование позволяет серверу работать эффективнее, поскольку оно избегает накладных расходов на повторное преобразование запроса, если он снова понадобится во время сессии. Преобразование и кэширование происходит для следующих запросов:

Подготовленные запросы, как те, которые обрабатываются на уровне SQL (используя запрос PREPARE), так и те, которые обрабатываются с помощью двоичного протокола клиент/сервер (используя функцию C API). Переменная системы max_prepared_stmt_count контролирует общее количество запросов, кэшируемых сервером. (Сумма количества подготовленных запросов по всем сессиям.)
Хранимые программы (хранимые процедуры и функции, триггеры и события). В этом случае сервер преобразует и кэширует весь текст программы. Переменная системы stored_program_cache указывает приблизительное количество хранимых программ, кэшируемых сервером на сессию.

Сервер поддерживает кэши подготовленных запросов и хранимых программ на основе каждой сессии. Запросы, кэшированные для одной сессии, недоступны для других сессий. Когда сессия заканчивается, сервер удаляет все кэшированные для неё запросы.

Когда сервер использует кэшированную внутреннюю структуру запроса, он должен следить за тем, чтобы структура не устаревала. Могут произойти изменения метаданных для объекта, используемого запросом, что вызовет несоответствие между текущим определением объекта и определением, представленным во внутренней структуре запроса. Изменения метаданных происходят для запросов DDL, таких как те, которые создают, удаляют, изменяют, переименовывают или усекают таблицы, или анализируют, оптимизируют или восстанавливают таблицы. Изменения содержимого таблицы (например, с помощью INSERT или UPDATE) не изменяют метаданные, также как и запросы SELECT.

Вот иллюстрация проблемы. Предположим, что клиент подготовил этот запрос:

PREPARE s1 FROM 'SELECT * FROM t1';

SELECT * расширяется во внутренней структуре до списка столбцов в таблице. Если набор столбцов в таблице изменяется с помощью ALTER TABLE, подготовленный запрос устаревает. Если сервер не обнаружит этого изменения при следующем выполнении клиентом s1, подготовленный запрос вернёт некорректные результаты.

Чтобы избежать проблем, вызванных изменениями метаданных таблиц или представлений, на которые ссылается подготовленный запрос, сервер обнаруживает эти изменения и автоматически переподготавливает запрос при его следующем выполнении. То есть, сервер повторно анализирует запрос и строит внутреннюю структуру заново. Переанализ также происходит после того, как ссылки на таблицы или представления очищаются из кэша определения таблиц, либо неявно, чтобы освободить место для новых записей в кэше, либо явно из-за FLUSH TABLES.

Аналогично, если происходят изменения объектов, используемых хранимой программой, сервер повторно анализирует затронутые запросы в рамках программы.

Сервер также обнаруживает изменения метаданных для объектов в выражениях. Они могут использоваться в запросах, специфичных для хранимых программ, таких как DECLARE CURSOR, или в управляющих конструкциях, таких как IF, CASE и RETURN.

Чтобы избежать повторного анализа всей хранимой программы, сервер переанализирует только необходимые запросы или выражения внутри программы. Примеры:

Предположим, что метаданные для таблицы или представления изменены. Переанализ происходит для SELECT * внутри программы, которая обращается к таблице или представлению, но не для SELECT *, которая не обращается к таблице или представлению.
Когда запрос затронут, сервер переанализирует его частично, если это возможно. Рассмотрим этот запрос CASE:
```
CASE case_expr
  WHEN when_expr1 ...
  WHEN when_expr2 ...
  WHEN when_expr3 ...
  ...
END CASE
```
Если изменения метаданных затрагивают только WHEN when_expr3, переанализируется это выражение. case_expr и другие WHEN выражения не переанализируются.

Переанализ выполняется с использованием базы данных и режима SQL по умолчанию, которые действовали при первоначальном преобразовании во внутреннюю форму.

Сервер пытается выполнить переанализ до трёх раз. Если все попытки завершатся неудачей, возникает ошибка.

Переанализ автоматичен, но в той мере, в которой он происходит, снижает производительность подготовленных запросов и хранимых программ.

Для подготовленных запросов переменная состояния Com_stmt_reprepare отслеживает количество переподготовок.