29.12.6 Performance Schema Statement Event Tables — MySQL 8.4

29.12.6 Таблицы событий выполнения запросов Performance Schema

Модуль Performance Schema отслеживает выполнение запросов. События запросов находятся на высоком уровне иерархии событий. В этой иерархии события ожидания вложены в события стадии, которые, в свою очередь, вложены в события запроса, а те — в события транзакций.

Эти таблицы хранят события запросов:

events_statements_current: Текущее событие запроса для каждого потока.
events_statements_history: Самые последние завершенные события запросов по потокам.
events_statements_history_long: Самые последние завершенные события запросов во всей системе (по всем потокам).
prepared_statements_instances: Экземпляры подготовленных запросов и статистика.

В следующих разделах описываются таблицы событий запросов. Также существуют сводные таблицы, агрегирующие информацию о событиях запросов; см. Раздел 29.12.20.3, “Сводные таблицы запросов”.

Для получения дополнительной информации об отношениях между тремя таблицами событий events_statements_xxx, см. Раздел 29.9, “Таблицы Performance Schema для текущих и исторических событий”.

Настройка сбора событий запросов

Для управления сбором событий запросов устанавливается состояние соответствующих инструментов и потребителей:

Таблица setup_instruments содержит инструменты с именами, начинающимися с statement. Используйте эти инструменты для включения или отключения сбора отдельных классов событий запросов.
Таблица setup_consumers содержит значения потребителей с именами, соответствующими именам текущих и исторических таблиц событий запросов, а также потребителю для отбора данных запросов. Используйте этих потребителей для фильтрации сбора событий запросов и агрегирования данных запросов.

Инструменты запросов включены по умолчанию, и потребители запросов events_statements_current, events_statements_history и statements_digest включены по умолчанию:

mysql> SELECT NAME, ENABLED, TIMED
       FROM performance_schema.setup_instruments
       WHERE NAME LIKE 'statement/%';
+---------------------------------------------+---------+-------+
| NAME                                        | ENABLED | TIMED |
+---------------------------------------------+---------+-------+
| statement/sql/select                        | YES     | YES   |
| statement/sql/create_table                  | YES     | YES   |
| statement/sql/create_index                  | YES     | YES   |
...
| statement/sp/stmt                           | YES     | YES   |
| statement/sp/set                            | YES     | YES   |
| statement/sp/set_trigger_field              | YES     | YES   |
| statement/scheduler/event                   | YES     | YES   |
| statement/com/Sleep                         | YES     | YES   |
| statement/com/Quit                          | YES     | YES   |
| statement/com/Init DB                       | YES     | YES   |
...
| statement/abstract/Query                    | YES     | YES   |
| statement/abstract/new_packet               | YES     | YES   |
| statement/abstract/relay_log                | YES     | YES   |
+---------------------------------------------+---------+-------+

mysql> SELECT *
       FROM performance_schema.setup_consumers
       WHERE NAME LIKE '%statements%';
+--------------------------------+---------+
| NAME                           | ENABLED |
+--------------------------------+---------+
| events_statements_current      | YES     |
| events_statements_history      | YES     |
| events_statements_history_long | NO      |
| statements_digest              | YES     |
+--------------------------------+---------+

Для управления сбором событий запросов при запуске сервера используйте такие строки в файле my.cnf:

Включить:

[mysqld]
performance-schema-instrument='statement/%=ON'
performance-schema-consumer-events-statements-current=ON
performance-schema-consumer-events-statements-history=ON
performance-schema-consumer-events-statements-history-long=ON
performance-schema-consumer-statements-digest=ON

Отключить:

[mysqld]
performance-schema-instrument='statement/%=OFF'
performance-schema-consumer-events-statements-current=OFF
performance-schema-consumer-events-statements-history=OFF
performance-schema-consumer-events-statements-history-long=OFF
performance-schema-consumer-statements-digest=OFF

Для управления сбором событий запросов во время работы сервера обновляйте таблицы setup_instruments и setup_consumers:

Включить:

UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME LIKE 'statement/%';

UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME LIKE '%statements%';

Отключить:

UPDATE performance_schema.setup_instruments
SET ENABLED = 'NO', TIMED = 'NO'
WHERE NAME LIKE 'statement/%';

UPDATE performance_schema.setup_consumers
SET ENABLED = 'NO'
WHERE NAME LIKE '%statements%';

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

Дополнительную информацию о настройке сбора событий см. в разделе 29.3, “Настройка Performance Schema при запуске”, и разделе 29.4, “Настройка Performance Schema во время работы”.

Мониторинг запросов

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

Когда модуль Performance Schema отслеживает запрос (команду сервера или SQL-запрос), он использует имена инструментов, проходящие стадии от более общих (или «абстрактных») к более конкретным, пока не достигнет конечного имени инструмента.

Конечные имена инструментов соответствуют командам сервера и SQL-запросам:

Команды сервера соответствуют значениям COM_xxx codes, определённым в заголовочном файле mysql_com.h и обработанным в sql/sql_parse.cc. Примеры включают COM_PING и COM_QUIT. Инструменты для команд имеют имена, начинающиеся с statement/com, например, statement/com/Ping и statement/com/Quit.
SQL-запросы выражаются в виде текста, например, DELETE FROM t1 или SELECT * FROM t2. Инструменты для SQL-запросов имеют имена, начинающиеся с statement/sql, например, statement/sql/delete и statement/sql/select.

Некоторые конечные имена инструментов специфичны для обработки ошибок:

statement/com/Error учитывает сообщения, полученные сервером вне основного потока. Это может быть полезно для определения клиентов с неправильной конфигурацией, использующих более новую версию MySQL, чем сервер, или клиентов, пытающихся атаковать сервер.
statement/sql/error учитывает SQL-запросы, которые не удаётся разобрать. Это может быть полезно для определения неправильно сформированных запросов, отправленных клиентом. Неправильно сформированный запрос отличается от запроса, который разбирается, но терпит неудачу из-за ошибки во время выполнения. Например, SELECT * FROM является неправильно сформированным, и используется инструмент statement/sql/error. В отличие от этого, SELECT * разбирается, но терпит неудачу с ошибкой No tables used. В этом случае используется инструмент statement/sql/select, и событие запроса содержит информацию, указывающую характер ошибки.

Запрос может поступать из следующих источников:

В виде команды или запроса от клиента, который отправляет запрос в виде пакетов.
В виде строки запроса, считанной из релейного журнала на реплике.
В виде события из планировщика событий.

Подробности запроса изначально неизвестны, и модуль Performance Schema переходит от абстрактных к конкретным именам инструментов в последовательности, зависящей от источника запроса.

Для запроса, полученного от клиента:

Когда сервер обнаруживает новый пакет на уровне сокета, начинается новый запрос с абстрактным именем инструмента statement/abstract/new_packet.
Когда сервер считывает номер пакета, он узнаёт больше о типе полученного запроса, и модуль Performance Schema уточняет имя инструмента. Например, если запрос — пакет COM_PING, имя инструмента становится statement/com/Ping, и это окончательное имя. Если запрос — пакет COM_QUERY, он соответствует SQL-запросу, но не конкретному типу. В этом случае инструмент меняется с одного абстрактного имени на более конкретное, но всё ещё абстрактное имя, statement/abstract/Query, и запрос требует дальнейшей классификации.
Если запрос — запрос, текст запроса считывается и передаётся анализатору. После анализа, точный тип запроса известен. Если, например, запрос — запрос INSERT, модуль Performance Schema уточняет имя инструмента с statement/abstract/Query до statement/sql/insert, что является окончательным именем.

Для запроса, считанного как запрос из релейного журнала на реплике:

Операторы в журнале репликации хранятся в виде текста и читаются как таковые. Нет сетевого протокола, поэтому инструмент statement/abstract/new_packet не используется. Вместо этого используется начальный инструмент statement/abstract/relay_log.
При разборе оператора точно известен тип оператора. Если, например, запрос представляет собой оператор INSERT, то Performance Schema уточняет имя инструмента с statement/abstract/Query до statement/sql/insert, которое является окончательным именем.

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

Для запроса, полученного от Планировщика событий:

Выполнение события инструментируется с использованием имени statement/scheduler/event. Это окончательное имя.

Операторы, выполняемые внутри тела события, инструментируются с использованием имен statement/sql/* без использования предварительного абстрактного инструмента. Событие — это хранимая программа, а хранимые программы предварительно компилируются в памяти перед выполнением. Следовательно, нет разбора во время выполнения, и тип каждого оператора известен к моменту его выполнения.

Операторы, выполняемые внутри тела события, являются дочерними операторами. Например, если событие выполняет оператор INSERT, выполнение самого события является родительским и инструментируется с помощью statement/scheduler/event, а оператор INSERT является дочерним и инструментируется с помощью statement/sql/insert. Отношение родитель/дочерний элемент сохраняется между отдельными инструментированными операциями. Это отличается от последовательности уточнения, которая происходит внутри одной инструментированной операции, от абстрактных до окончательных имен инструментов.

Для сбора статистики по операторам недостаточно включить только окончательные инструменты statement/sql/*, используемые для отдельных типов операторов. Также необходимо включить абстрактные инструменты statement/abstract/*. Обычно это не должно вызывать проблем, поскольку все инструменты операторов включены по умолчанию. Однако приложение, которое выборочно включает или выключает инструменты операторов, должно учитывать, что отключение абстрактных инструментов также отключает сбор статистики для отдельных инструментов операторов. Например, для сбора статистики по операторам INSERT, необходимо включить statement/sql/insert, а также statement/abstract/new_packet и statement/abstract/Query. Аналогично, для инструментирования реплицированных операторов необходимо включить statement/abstract/relay_log.

Для абстрактных инструментов, таких как statement/abstract/Query, статистика не агрегируется, поскольку ни один оператор никогда не классифицируется с абстрактным инструментом в качестве окончательного имени оператора.