Spec-Zone .ru
спецификации, руководства, описания, API
|
Для определенных операторов, которые клиент мог бы выполнить многократно во время сеанса, сервер преобразовывает оператор во внутреннюю структуру и кэши что структура, которая будет использоваться во время выполнения. Кэширование позволяет серверу выполнить более эффективно, потому что это избегает, чтобы издержки перепреобразования оператора были должны это быть необходимыми снова во время сеанса. Преобразование и кэширование происходят для этих операторов:
Готовые операторы, оба обработанные на уровне SQL (использующий PREPARE
оператор) и те обработанное использование двоичного
клиент-серверного протокола (использующий mysql_stmt_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
.
Чтобы избежать повторно анализировать все сохраненные программы, сервер повторно анализирует операторы, на которые влияют, или выражения в пределах программы только как необходимый. Примеры:
Предположите, что метаданные для таблицы или представления изменяются. Перепарсинг
происходит для a SELECT *
в пределах программы, которая получает доступ к
таблице или представлению, но не для a SELECT *
это не получает доступ к
таблице или представлению.
Когда на оператор влияют, сервер повторно анализирует его только частично если
возможный. Рассмотрите это CASE
оператор:
CASEcase_expr
WHENwhen_expr1
... WHENwhen_expr2
... WHENwhen_expr3
... ...END CASE
Если изменение метаданных влияет только WHEN
,
то выражение повторно анализируется. when_expr3
case_expr
и другой
WHEN
выражения не повторно анализируются.
Перепарсинг использует базу данных значения по умолчанию и режим SQL, которые были в действительности для исходного преобразования во внутреннюю форму.
Попытки сервера, повторно анализирующие до трех раз. Ошибка происходит, если все попытки перестали работать.
Перепарсинг является автоматическим, но до такой степени, что он происходит, уменьшает подготовленный оператор и сохраненную производительность программы.
Для готовых операторов, Com_stmt_reprepare
переменная состояния отслеживает число переприготовлений.