25.4.2 Performance Schema Event Filtering — MySQL 5.7

25.4.2 Фильтрация событий Performance Schema

События обрабатываются в режиме «производитель/потребитель»:

Инструментированный код является источником событий и производит события для сбора. Таблица setup_instruments перечисляет инструменты, для которых могут собираться события, их включение и (для включённых инструментов) сбор информации о времени выполнения:
```
mysql> SELECT * FROM performance_schema.setup_instruments;
+---------------------------------------------------+---------+-------+
| NAME                                              | ENABLED | TIMED |
+---------------------------------------------------+---------+-------+
...
| wait/synch/mutex/sql/LOCK_global_read_lock        | YES     | YES   |
| wait/synch/mutex/sql/LOCK_global_system_variables | YES     | YES   |
| wait/synch/mutex/sql/LOCK_lock_db                 | YES     | YES   |
| wait/synch/mutex/sql/LOCK_manager                 | YES     | YES   |
...
```
Таблица setup_instruments предоставляет самый базовый способ управления производством событий. Для дальнейшей детализации производства событий на основе типа объекта или потока, которые отслеживаются, могут использоваться другие таблицы, как описано в разделе 25.4.3 «Предварительная фильтрация событий».

Таблицы Performance Schema являются пунктами назначения для событий и потребляют события. Таблица setup_consumers перечисляет типы потребителей, которым может быть отправлена информация о событиях, и включены ли они:

mysql> SELECT * FROM performance_schema.setup_consumers;
+----------------------------------+---------+
| NAME                             | ENABLED |
+----------------------------------+---------+
| events_stages_current            | NO      |
| events_stages_history            | NO      |
| events_stages_history_long       | NO      |
| events_statements_current        | YES     |
| events_statements_history        | YES     |
| events_statements_history_long   | NO      |
| events_transactions_current      | NO      |
| events_transactions_history      | NO      |
| events_transactions_history_long | NO      |
| events_waits_current             | NO      |
| events_waits_history             | NO      |
| events_waits_history_long        | NO      |
| global_instrumentation           | YES     |
| thread_instrumentation           | YES     |
| statements_digest                | YES     |
+----------------------------------+---------+

Фильтрация может выполняться на разных этапах мониторинга производительности:

Предварительная фильтрация. Это делается путем изменения конфигурации Performance Schema, так что собираются только определенные типы событий от производителей, а собранные события обновляют только определенные потребители. Для этого можно включить или отключить инструменты или потребителей. Предварительная фильтрация выполняется Performance Schema и имеет глобальное действие, применимое ко всем пользователям.

Причины использования предварительной фильтрации:
- Для уменьшения накладных расходов. Накладные расходы Performance Schema должны быть минимальными даже при включении всех инструментов, но, возможно, вы хотите уменьшить их ещё больше. Или вас не интересуют временные события, и вы хотите отключить код времени выполнения, чтобы устранить временные накладные расходы.
- Для предотвращения заполнения таблиц текущих событий или истории событиями, которые вас не интересуют. Предварительная фильтрация оставляет больше «“пространства” в этих таблицах для примеров строк для включённых типов инструментов. Если вы включите только инструменты файлов с предварительной фильтрацией, для инструментов, не являющихся файлами, строки не собираются. При пост-фильтрации события, не являющиеся файлами, собираются, оставляя меньше строк для событий файлов.
- Для избежания обслуживания некоторых типов таблиц событий. Если вы отключаете потребителя, сервер не тратит время на поддержание пунктов назначения для этого потребителя. Например, если вас не интересуют истории событий, вы можете отключить потребителей истории таблиц для повышения производительности.
Пост-фильтрация. Это подразумевает использование WHERE-клаузул в запросах, которые выбирают информацию из таблиц Performance Schema, чтобы указать, какие из доступных событий вы хотите увидеть. Пост-фильтрация выполняется на основе каждого пользователя, поскольку отдельные пользователи выбирают, какие из доступных событий их интересуют.

Причины использования пост-фильтрации:
- Для того, чтобы избежать принятия решений для отдельных пользователей о том, какая информация о событиях их интересует.
- Для использования Performance Schema для расследования проблемы производительности, когда ограничения, которые нужно наложить, используя предварительную фильтрацию, неизвестны заранее.

В следующих разделах более подробно рассматривается предварительная фильтрация и приводятся рекомендации по наименованию инструментов или потребителей в операциях фильтрации. Сведения о написании запросов для получения информации (пост-фильтрация) см. в разделе 25.5 «Запросы к Performance Schema».