29.4.2 Performance Schema Event Filtering — MySQL 8.4

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

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

Инструментированный код является источником событий и производит события для сбора. Таблица setup_instruments перечисляет инструменты, для которых могут собираться события, указывает, включены ли они, и (для включенных инструментов) нужно ли собирать временные данные:
```
mysql> SELECT NAME, ENABLED, TIMED
       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 предоставляет наиболее базовый способ управления производством событий. Для дальнейшего уточнения производства событий на основе типа контролируемого объекта или потока можно использовать другие таблицы, как описано в разделе 29.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_cpu            | NO      |
| events_statements_current        | YES     |
| events_statements_history        | YES     |
| events_statements_history_long   | NO      |
| events_transactions_current      | YES     |
| events_transactions_history      | YES     |
| 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 для расследования проблемы производительности, когда ограничения, которые нужно наложить с помощью предварительной фильтрации, заранее неизвестны.

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