25.12.6 Performance Schema Statement Event Tables — MySQL 5.7

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

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

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

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

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

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

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

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

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

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

mysql> SELECT *
       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%';

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

Таблица setup_timers содержит строку с значением NAME равным statement, которая указывает единицу измерения для времени событий запросов. По умолчанию используется единица NANOSECOND:

mysql> SELECT *
       FROM performance_schema.setup_timers
       WHERE NAME = 'statement';
+-----------+------------+
| NAME      | TIMER_NAME |
+-----------+------------+
| statement | NANOSECOND |
+-----------+------------+

Для изменения единицы измерения, измените значение TIMER_NAME:

UPDATE performance_schema.setup_timers
SET TIMER_NAME = 'MICROSECOND'
WHERE NAME = 'statement';

Для дополнительной информации о настройке сбора событий см. Раздел 25.3, «Настройка Performance Schema при запуске» и Раздел 25.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, потому что ни одно заявление никогда не классифицируется с абстрактным инструментом в качестве окончательного имени заявления.