RussianLDP Рейтинг@Mail.ru
WebMoney: 
WMZ Z294115950220 
WMR R409981405661 
WME E134003968233 
Visa 
4274 3200 2453 6495 

Глава 23. MySQL Performance Schema

MySQL Performance Schema особенность контроля выполнения MySQL Server на низком уровне. У Performance Schema есть эти характеристики:

  • Performance Schema обеспечивает способ осмотреть внутреннее выполнение сервера во времени выполнения. Это осуществлено, используя механизм хранения PERFORMANCE_SCHEMA и базу данных performance_schema. Performance Schema сосредотачивается прежде всего на характеристиках. Это отличается от INFORMATION_SCHEMA, которая служит для просмотра метаданных.

  • Performance Schema следит за развитием событий сервера. Событие является чем-либо, что сервер делает, что занимает время и было инструментовано так, чтобы информация синхронизации могла быть собрана. Вообще, случаем мог быть вызов функции, ожидание операционной системы, этапа выполнения запроса SQL, такого как парсинг или сортировка, всего запроса или группы запросов. Набор событий обеспечивает доступ к информации о требованиях синхронизации файла и табличного ввода/вывода, табличные блокировки и т.д. для сервера и для нескольких механизмов хранения.
  • События Performance Schema отличны от событий, записанных в двоичный журнал сервера (которые описывают модификации данных) и событий Event Scheduler (которые являются типом сохраненной программы).
  • События Performance Schema являются определенными для приведенного примера MySQL Server. Таблицы Performance Schema считаются локальными для сервера, и изменения в них не копируются в двоичный журнал.
  • Текущие события доступны, так же как истории событий и резюме. Это позволяет Вам определить, сколько инструментованных действий было выполнено и сколько времени они заняли. Информация о событии доступна, чтобы показать действия определенных потоков или деятельность, связанную с особыми объектами, такими как mutex или файл.
  • Механизм хранения PERFORMANCE_SCHEMA собирает данные событий, используя точки инструментовки в исходном коде сервера.
  • Собранные события сохранены в таблицах в базе данных performance_schema. Эти таблицы могут быть запрошены, используя SELECT как другие таблицы.
  • Конфигурация Performance Schema может быть изменена динамически, обновляя таблицы в базе данных performance_schema через запросы SQL. Конфигурация немедленно изменяет сбор данных.
  • Таблицы в базе данных performance_schema это представления или временные таблицы, которые не используют постоянного хранения на диске.
  • Контроль доступен на всех платформах, поддержанных MySQL.

    Некоторые ограничения могут применяться: типы таймеров могут изменяться для платформы. Инструменты, которые относятся к механизмам хранения, не могут быть осуществлены для всех механизмов хранения. Инструментовка каждого имеющего отношение к третьей стороне механизма ответственность автора механизма. См. также раздел C.8.

  • Сбор данных осуществлен, изменяя исходный код сервера, чтобы добавить инструментовку. Нет никаких отдельных потоков, связанных с Performance Schema, в отличие от других особенностей, таких как репликация или Event Scheduler.

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

  • Активирование Performance Schema не вызывает изменений в поведении сервера. Например, это не вызывает поток, намечающий измениться, и это не меняет план выполнения запроса (как показано EXPLAIN).

  • Контроль сервера происходит непрерывно и незаметно с очень малыми издержками. Активирование Performance Schema не делает сервер непригодным.
  • Анализатор неизменен. Нет никаких новых ключевых слов или запросов.
  • Выполнение сервера обычно работает нормально, даже если Performance Schema терпит неудачу внутренне.
  • Когда есть выбор между выполнением обработки во время набора событий первоначально или во время извлечения событий позже, приоритет дан созданию набора быстрее. Это потому, что набор является процессом, тогда как извлечение происходит по требованию и могло бы не происходить вообще.
  • Большинство таблиц Performance Schema имеет индекс, который предоставляет доступ к планам выполнения, кроме полного сканирования таблицы. Для получения дополнительной информации см. раздел 9.2.5.
  • Легко добавить новые пункты инструментовки.
  • Если выполнение инструментовки изменится, то ранее инструментованный код продолжит работать. Это приносит пользу разработчикам, имеющим отношение к плагинам, потому что не надо обновлять каждый плагин, чтобы остаться синхронизированным с последними изменениями Performance Schema.

MySQL sys schema ряд объектов, который обеспечивает удобный доступ к данным, собранным Performance Schema. sys schema установлена по умолчанию. Для инструкций см. раздел 24.

23.1. Быстрый запуск Performance Schema

Этот раздел кратко начинает Performance Schema с примеров, которые показывают, как использовать это. Для дополнительных примеров см. раздел 23.16.

Чтобы Performance Schema была доступна, она должна быть сконфигурирована, когда MySQL был создан. Вы можете проверить обстоит ли дело так, проверяя вывод сервера. Если Performance Schema доступна, то вывод упомянет несколько переменных с именами, которые начинаются с performance_schema:

shell> mysqld --verbose --help
...
  --performance_schema
Enable the performance schema.
  --performance_schema_events_waits_history_long_size=#
Number of rows in events_waits_history_long.
...

Если такие переменные не появляются в выводе, Ваш сервер не был создан, чтобы поддерживать Performance Schema. В этом случае см. раздел 23.2.

Предполагая, что Performance Schema доступна, она включена по умолчанию. Чтобы включить или отключить это явно, запустите сервер с соответствующим значением переменной performance_schema. Например, используйте эти строки в Вашем файле my.cnf:

[mysqld]
performance_schema=ON

Когда сервер запускается, он видит performance_schema и попытается инициализировать Performance Schema. Чтобы проверить успешную инициализацию, используйте этот запрос:

mysql> SHOW VARIABLES LIKE 'performance_schema';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| performance_schema | ON    |
+--------------------+-------+

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

Performance Schema осуществлена как механизм хранения. Если этот механизм доступен (это Вы должны были уже проверить ранее), Вы должны видеть, что он перечислен со значением YES столбца SUPPORT таблицы INFORMATION_SCHEMA.ENGINES или вывода SHOW ENGINES:

mysql> SELECT * FROM INFORMATION_SCHEMA.ENGINES
                   WHERE ENGINE='PERFORMANCE_SCHEMA'\G
*************************** 1. row ***************************
ENGINE: PERFORMANCE_SCHEMA
 SUPPORT: YES
 COMMENT: Performance Schema
TRANSACTIONS: NO
XA: NO
  SAVEPOINTS: NO

mysql> SHOW ENGINES\G
...
Engine: PERFORMANCE_SCHEMA
 Support: YES
 Comment: Performance Schema
Transactions: NO
XA: NO
  Savepoints: NO
...

Механизм хранения PERFORMANCE_SCHEMA воздействует на таблицы в базе данных performance_schema. Вы можете сделать базу данных performance_schema базой данных по умолчанию так, чтобы ссылки на ее таблицы не были квалифицированы с именем базы данных:

mysql> USE performance_schema;

Много примеров в этой главе принимают performance_schema как базу данных по умолчанию.

Таблицы Performance Schema сохранены в базе данных performance_schema. Информация о структуре этой базы данных и ее таблиц может быть получена как для любой другой базы данных, выбирая из INFORMATION_SCHEMA или при использовании SHOW. Например, используйте любой из этих запросов, чтобы видеть, какие таблицы Performance Schema существуют:

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
                 WHERE TABLE_SCHEMA = 'performance_schema';
+------------------------------------------------+
| TABLE_NAME                                     |
+------------------------------------------------+
| accounts                                       |
| cond_instances                                 |
...
| events_stages_current                          |
| events_stages_history                          |
| events_stages_history_long                     |
| events_stages_summary_by_account_by_event_name |
| events_stages_summary_by_host_by_event_name    |
| events_stages_summary_by_thread_by_event_name  |
| events_stages_summary_by_user_by_event_name    |
| events_stages_summary_global_by_event_name     |
| events_statements_current                      |
| events_statements_history                      |
| events_statements_history_long                 |
...
| file_instances                                 |
| file_summary_by_event_name                     |
| file_summary_by_instance                       |
| host_cache                                     |
| hosts                                          |
| memory_summary_by_account_by_event_name        |
| memory_summary_by_host_by_event_name           |
| memory_summary_by_thread_by_event_name         |
| memory_summary_by_user_by_event_name           |
| memory_summary_global_by_event_name            |
| metadata_locks                                 |
| mutex_instances                                |
| objects_summary_global_by_type                 |
| performance_timers                             |
| replication_connection_configuration           |
| replication_connection_status                  |
| replication_applier_configuration              |
| replication_applier_status                     |
| replication_applier_status_by_coordinator      |
| replication_applier_status_by_worker           |
| rwlock_instances                               |
| session_account_connect_attrs                  |
| session_connect_attrs                          |
| setup_actors                                   |
| setup_consumers                                |
| setup_instruments                              |
| setup_objects                                  |
| setup_timers                                   |
| socket_instances                               |
| socket_summary_by_event_name                   |
| socket_summary_by_instance                     |
| table_handles                                  |
| table_io_waits_summary_by_index_usage          |
| table_io_waits_summary_by_table                |
| table_lock_waits_summary_by_table              |
| threads                                        |
| users                                          |
+------------------------------------------------+

mysql> SHOW TABLES FROM performance_schema;
+------------------------------------------------------+
| Tables_in_performance_schema |
+------------------------------------------------------+
| accounts   |
| cond_instances   |
| events_stages_current  |
| events_stages_history  |
| events_stages_history_long   |
...

Число таблиц Performance Schema увеличится в течение долгого времени как выполнение дополнительных инструментов.

Название базы данных performance_schema в нижнем регистре, как и названия таблиц в ее пределах. Запросы должны определить имена в нижнем регистре.

Чтобы видеть структуру отдельных таблиц, надо использовать SHOW CREATE TABLE:

mysql> SHOW CREATE TABLE setup_timers\G
*************************** 1. row ***************************
 Table: setup_timers
Create Table: CREATE TABLE `setup_timers` (
  `NAME` varchar(64) NOT NULL,
  `TIMER_NAME` enum('CYCLE','NANOSECOND','MICROSECOND','MILLISECOND','TICK')
   NOT NULL) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8

Структура таблицы также доступна, выбирая из таких таблиц, как INFORMATION_SCHEMA.COLUMNS или при использовании запросов SHOW COLUMNS.

Таблицы в performance_schema могут быть сгруппированы согласно типу информации в них: текущие события, истории событий и резюме, экземпляры объектов и информацию конфигурации. Следующие примеры иллюстрируют несколько вариантов использования для этих таблиц. Для получения дальнейшей информации о таблицах в каждой группе см. раздел 23.9.

Первоначально, не все инструменты и потребители включены, таким образом, performance schema не собирает все события. Чтобы включить всех их и включить синхронизацию событий, выполните два запроса (количество строк может отличаться в зависимости от версии MySQL):

mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES';
Query OK, 560 rows affected (0.04 sec)
mysql> UPDATE setup_consumers SET ENABLED = 'YES';
Query OK, 10 rows affected (0.00 sec)

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

mysql> SELECT * FROM events_waits_current\G
*************************** 1. row ***************************
THREAD_ID: 0
 EVENT_ID: 5523
 EVENT_NAME: wait/synch/mutex/mysys/THR_LOCK::mutex
   SOURCE: thr_lock.c:525
TIMER_START: 201660494489586
TIMER_END: 201660494576112
 TIMER_WAIT: 86526
SPINS: NULL
  OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 142270668
 NESTING_EVENT_ID: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: 0
...

Этот случай указывает, что поток 0 ждал 86526 пикосекунд, чтобы приобрести блокировку на THR_LOCK::mutex, mutex в подсистеме mysys. Первые несколько столбцов предоставляют следующую информацию:

  • ID столбца указывают, какой поток прибывает и число событий.

  • EVENT_NAME указывает на то, что было инструментовано и SOURCE указывает, какой исходный файл содержит инструментованный код.
  • Столбцы таймера показывают, когда случай запустился и остановился и сколько времени это заняло. Если случай все еще происходит, TIMER_END и TIMER_WAIT NULL. Значения таймера приблизительны и выражены в пикосекундах. Для информации о таймерах и времени событий см. раздел 23.2.3.1.

Таблицы истории содержат тот же самый вид строк как таблица текущих событий, но имеют больше строк и показывают то, что сервер делал. Таблицы events_waits_history и events_waits_history_long содержат самые свежие 10 событий на поток и новые 10000 событий, соответственно. Например, чтобы увидеть информацию для недавних событий, произведенных потоком 13, сделайте это:

mysql> SELECT EVENT_ID, EVENT_NAME, TIMER_WAIT
                 FROM events_waits_history WHERE THREAD_ID = 13
                 ORDER BY EVENT_ID;
+----------+-----------------------------------------+------------+
| EVENT_ID | EVENT_NAME                              | TIMER_WAIT |
+----------+-----------------------------------------+------------+
| 86       | wait/synch/mutex/mysys/THR_LOCK::mutex  | 686322     |
| 87       | wait/synch/mutex/mysys/THR_LOCK_malloc  | 320535     |
| 88       | wait/synch/mutex/mysys/THR_LOCK_malloc  | 339390     |
| 89       | wait/synch/mutex/mysys/THR_LOCK_malloc  | 377100     |
| 90       | wait/synch/mutex/sql/LOCK_plugin        | 614673     |
| 91       | wait/synch/mutex/sql/LOCK_open          | 659925     |
| 92       | wait/synch/mutex/sql/THD::LOCK_thd_data | 494001     |
| 93       | wait/synch/mutex/mysys/THR_LOCK_malloc  | 222489     |
| 94       | wait/synch/mutex/mysys/THR_LOCK_malloc  | 214947     |
| 95       | wait/synch/mutex/mysys/LOCK_alarm       | 312993     |
+----------+-----------------------------------------+------------+

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

Сводные таблицы предоставляют соединенную информацию для всех событий в течение долгого времени. Таблицы в этой группе суммируют данные событий по-разному. Чтобы видеть, какие инструменты были запущены большинство раз или заняли больше времени, сортируют таблицу events_waits_summary_global_by_event_name по столбцу COUNT_STAR или SUM_TIMER_WAIT, которые соответствуют COUNT(*) или SUM(TIMER_WAIT), соответственно, вычисленным по всем событиям:

mysql> SELECT EVENT_NAME, COUNT_STAR
                 FROM events_waits_summary_global_by_event_name
                 ORDER BY COUNT_STAR DESC LIMIT 10;
+---------------------------------------------------+------------+
| EVENT_NAME                                        | COUNT_STAR |
+---------------------------------------------------+------------+
| wait/synch/mutex/mysys/THR_LOCK_malloc            | 6419       |
| wait/io/file/sql/FRM                              |  452       |
| wait/synch/mutex/sql/LOCK_plugin                  |  337       |
| wait/synch/mutex/mysys/THR_LOCK_open              |  187       |
| wait/synch/mutex/mysys/LOCK_alarm                 |  147       |
| wait/synch/mutex/sql/THD::LOCK_thd_data           |  115       |
| wait/io/file/myisam/kfile                         |  102       |
| wait/synch/mutex/sql/LOCK_global_system_variables |   89       |
| wait/synch/mutex/mysys/THR_LOCK::mutex            |   89       |
| wait/synch/mutex/sql/LOCK_open                    |   88       |
+---------------------------------------------------+------------+

mysql> SELECT EVENT_NAME, SUM_TIMER_WAIT
                 FROM events_waits_summary_global_by_event_name
                 ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;
+----------------------------------------+----------------+
| EVENT_NAME                             | SUM_TIMER_WAIT |
+----------------------------------------+----------------+
| wait/io/file/sql/MYSQL_LOG             | 1599816582     |
| wait/synch/mutex/mysys/THR_LOCK_malloc | 1530083250     |
| wait/io/file/sql/binlog_index          | 1385291934     |
| wait/io/file/sql/FRM                   | 1292823243     |
| wait/io/file/myisam/kfile              |  411193611     |
| wait/io/file/myisam/dfile              |  322401645     |
| wait/synch/mutex/mysys/LOCK_alarm      |  145126935     |
| wait/io/file/sql/casetest              |  104324715     |
| wait/synch/mutex/sql/LOCK_plugin       |   86027823     |
| wait/io/file/sql/pid                   |   72591750     |
+----------------------------------------+----------------+

Эти результаты показывают, что THR_LOCK_malloc востребована с точки зрения того, как часто используется и количества времени, которое потоки ждут, пытаясь приобрести это.

THR_LOCK_malloc mutex используется только в отладке.

Таблицы документируют, какие типы объектов инструментованы. Инструментованный объект, когда используется сервером, производит случай. Эти таблицы обеспечивают имена событий и примечания или информацию о статусе. Например, таблица file_instances приводит случаи инструментов для операций ввода/вывода файла и их связанных файлов:

mysql> SELECT * FROM file_instances\G
*************************** 1. row ***************************
 FILE_NAME: /opt/mysql-log/60500/binlog.000007
EVENT_NAME: wait/io/file/sql/binlog
OPEN_COUNT: 0
*************************** 2. row ***************************
 FILE_NAME: /opt/mysql/60500/data/mysql/tables_priv.MYI
EVENT_NAME: wait/io/file/myisam/kfile
OPEN_COUNT: 1
*************************** 3. row ***************************
 FILE_NAME: /opt/mysql/60500/data/mysql/columns_priv.MYI
EVENT_NAME: wait/io/file/myisam/kfile
OPEN_COUNT: 1
...

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

mysql> SELECT * FROM setup_timers;
+-------------+-------------+
| NAME        | TIMER_NAME  |
+-------------+-------------+
| idle        | MICROSECOND |
| wait        | CYCLE       |
| stage       | NANOSECOND  |
| statement   | NANOSECOND  |
| transaction | NANOSECOND  |
+-------------+-------------+

setup_instruments перечисляет набор инструментов, для которых события могут быть собраны и показывает, которые из них включены:

mysql> SELECT * FROM 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   |
...
| wait/synch/rwlock/sql/LOCK_grant                  | YES     | YES   |
| wait/synch/rwlock/sql/LOGGER::LOCK_logger         | YES     | YES   |
| wait/synch/rwlock/sql/LOCK_sys_init_connect       | YES     | YES   |
| wait/synch/rwlock/sql/LOCK_sys_init_slave         | YES     | YES   |
...
| wait/io/file/sql/binlog                           | YES     | YES   |
| wait/io/file/sql/binlog_index                     | YES     | YES   |
| wait/io/file/sql/casetest                         | YES     | YES   |
| wait/io/file/sql/dbopt                            | YES     | YES   |
...

Чтобы понять, как интерпретировать инструментальные имена см. раздел 23.4.

Чтобы управлять тем, собраны ли события для инструмента, устанавливайте значение ENABLED в YES или NO:

mysql> UPDATE setup_instruments SET ENABLED = 'NO'
                 WHERE NAME = 'wait/synch/mutex/sql/LOCK_mysql_create_db';

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

mysql> SELECT * FROM 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 как место назначения для информации о событии, устанавливайте ENABLED.

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

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

23.2. Конфигурация Performance Schema

Чтобы использовать MySQL Performance Schema, эти соображения конфигурации применяются:

  • Performance Schema должна быть сконфигурирована в ходе сборки MySQL Server, чтобы она была доступна. Performance Schema включена в двоичные дистрибутивы MySQL. Если Вы создаете пакет из исходных текстов, Вы должны гарантировать, что он сконфигурирован как описано в разделе 23.2.1 .

  • Performance Schema должна быть позволена при запуске сервера, чтобы позволить набору событий произойти. Опции Performance Schema могут быть активированы при запуске сервера или во времея выполнения, чтобы управлять, какие типы событий происходят. См. разделы 23.2.2, 23.2.3 и 23.2.3.2.

23.2.1. Создание конфигурации Performance Schema

Если Вы создаете MySQL из исходных текстов, включите Performance Schema запуском CMake с опцией WITH_PERFSCHEMA_STORAGE_ENGINE:

shell> cmake . -DWITH_PERFSCHEMA_STORAGE_ENGINE=1

Конфигурирование MySQL с опцией -DWITHOUT_PERFSCHEMA_STORAGE_ENGINE=1 запрещает включение Performance Schema, так что, если Вы хотите включить, не используйте эту опцию. См. раздел 2.8.4 .

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

shell> cmake . -DWITH_PERFSCHEMA_STORAGE_ENGINE=1 \
                  -DDISABLE_PSI_STAGE=1 \
                  -DDISABLE_PSI_STATEMENT=1

Для получения дополнительной информации см. описания опций DISABLE_PSI_XXX CMake в разделе 2.8.4.

Если Вы устанавливаете MySQL по предыдущей установке, которая была сконфигурирована без Performance Schema (или с более старой версией Performance Schema, у которой, возможно, нет всех текущих таблиц), выполните mysql_upgrade после запуска сервера, чтобы гарантировать, что база данных performance_schema существует со всеми текущими таблицами. Тогда перезапустите сервер. Один признак, что Вы должны сделать это, является присутствием сообщений, таких как следующее в журнале ошибок:

[ERROR] Native table 'performance_schema'.'events_waits_history'
        has the wrong structure
[ERROR] Native table 'performance_schema'.'events_waits_history_long'
        has the wrong structure
...

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

shell> mysqld --verbose --help
...
  --performance_schema
Enable the performance schema.
  --performance_schema_events_waits_history_long_size=#
Number of rows in events_waits_history_long.
...

Вы можете также соединиться с сервером и искать строку, которая называет механизм хранения PERFORMANCE_SCHEMA в выводе SHOW ENGINES:

mysql> SHOW ENGINES\G
...
Engine: PERFORMANCE_SCHEMA
 Support: YES
 Comment: Performance Schema
Transactions: NO
XA: NO
  Savepoints: NO
...

Если Performance Schema не была сконфигурирована в сервер, никакой строки для PERFORMANCE_SCHEMA не появится в выводе SHOW ENGINES. Вы могли бы видеть performance_schema перечисленную в выводе SHOW DATABASES, но у этого не будет никаких таблиц, и Вы не будете в состоянии использовать это.

Строка для PERFORMANCE_SCHEMA в SHOW ENGINES означает, что Performance Schema доступна, а не то, что это включено. Чтобы включить, Вы должны сделать так при запуске сервера, как описано в следующем разделе.

23.2.2. Конфигурация запуска Performance Schema

Предполагая, что Performance Schema доступна, она включена по умолчанию. Чтобы включить или отключить это явно, запустите сервер с переменной performance_schema , установленной к соответствующему значению. Например, используйте эти строки в Вашем файле my.cnf:

[mysqld]
performance_schema=ON

Если сервер неспособен выделить какой-либо внутренний буфер во время инициализации Performance Schema, то Performance Schema отключается и устанавливает performance_schema в OFF, а сервер работает без инструментовки.

Performance Schema также разрешает настроить инструмент и потребительскую конфигурацию при запуске сервера.

Чтобы управлять инструментом при запуске сервера, используйте опцию этой формы:

--performance-schema-instrument='instrument_name=value'

Здесь instrument_name инструментальное имя, такое как wait/synch/mutex/sql/LOCK_open, а value одно из этих значений:

  • OFF, FALSE или 0: Отключите инструмент.

  • ON, TRUE или 1: Включить и измерять время.
  • COUNTED: Включить и считать инструмент.

Каждая опция --performance-schema-instrument может определить только одно инструментальное имя, но много копий опции могут быть приведены, чтобы сконфигурировать много инструментов. Кроме того, образцы разрешены в инструментальных именах, чтобы сконфигурировать инструменты, которые соответствуют образцу. Чтобы сконфигурировать все инструменты синхронизации условия как включенные и считающиеся, используйте эту опцию:

--performance-schema-instrument='wait/synch/cond/%=COUNTED'

Чтобы отключить все инструменты, используйте эту опцию:

--performance-schema-instrument='%=OFF'

Исключение: инструменты memory/performance_schema/% встроены и не могут быть отключены при запуске.

Более длинные инструментальные строки имен имеют приоритет над более коротким образцами имен, независимо от порядка. Для информации об определении образцов, чтобы выбрать инструменты, см. раздел 23.2.3.9.

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

Чтобы управлять потребителем при запуске сервера, используйте опцию этой формы:

--performance-schema-consumer-consumer_name=value

Здесь consumer_name потребительское имя, такое как events_waits_history, а value одно из этих значений:

  • OFF, FALSE или 0: Не собирать события для потребителя.

  • ON, TRUE или 1: Собирать события для потребителя.

Например, чтобы включить потребителя events_waits_history, используйте эту опцию:

--performance-schema-consumer-events-waits-history=ON

Разрешенные потребительские имена могут быть найдены, исследуя таблицу setup_consumers. Образцы не разрешены. Потребитель называется в таблице setup_consumers с применением подчеркивания, но для потребительского набора при запуске тире и подчеркивания в пределах имени эквивалентны.

Performance Schema включает несколько системных переменных, которые предоставляют информацию о конфигурации:

mysql> SHOW VARIABLES LIKE 'perf%';
+--------------------------------------------------------+-------+
| Variable_name                                          | Value |
+--------------------------------------------------------+-------+
| performance_schema                                     |    ON |
| performance_schema_accounts_size                       |   100 |
| performance_schema_digests_size                        |   200 |
| performance_schema_events_stages_history_long_size     | 10000 |
| performance_schema_events_stages_history_size          |    10 |
| performance_schema_events_statements_history_long_size | 10000 |
| performance_schema_events_statements_history_size      |    10 |
| performance_schema_events_waits_history_long_size      | 10000 |
| performance_schema_events_waits_history_size           |    10 |
| performance_schema_hosts_size                          |   100 |
| performance_schema_max_cond_classes                    |    80 |
| performance_schema_max_cond_instances                  |  1000 |
...

Переменная performance_schema ON или OFF, чтобы указать, включена ли Performance Schema. Другие переменные указывают на табличные размеры (число строк) или значения распределения памяти.

С включенной Performance Schema число случаев Performance Schema затрагивает память сервера, возможно в большой степени. Performance Schema автомасштабирует много параметров, чтобы использовать память только как требуется, см. раздел 23.14.

Чтобы изменить значение системных переменных Performance Schema, установите их при запуске сервера. Например, поместите следующие строки в файл my.cnf, чтобы изменить размеры таблиц истории для события:

[mysqld]
performance_schema
performance_schema_events_waits_history_size=20
performance_schema_events_waits_history_long_size=15000

Performance Schema автоматически измеряет значения нескольких из ее параметров при запуске сервера, если они не установлены явно. Например, это измеряет параметры, которые управляют размерами событий. Performance Schema выделяет память, масштабируя ее использование к фактической загрузке сервера вместо того, чтобы выделить всю память, которая требуется во время запуска сервера. Следовательно, много параметров калибровки не должны быть установлены вообще. Чтобы видеть, какие параметры автоизмерены или автомасштабируются, используйте mysqld --verbose --help и исследуйте описания опции.

Для каждого авторазмерного параметра, который не установлен при запуске сервера (или установле в -1) Performance Schema определяет, как установить значение, основанное на значении следующих системных значений, которые рассматривают как подсказки о том, как Вы сконфигурировали свой сервер MySQL:

max_connections
open_files_limit
table_definition_cache
table_open_cache

Чтобы переопределить автокалибровку или автомасштабирование для данного параметра, установите это в значение не -1 при запуске. В этом случае Performance Schema назначает этому указанное значение.

Во временя выполнения SHOW VARIABLES выводит на экран фактические значения, к которым были установлены автоизмеренные параметры. Автомасштабируемые параметры выводятся на экран со значением -1.

Если Performance Schema отключена, ее авторазмерные и автомасштабируемые параметры остаются установленными в -1 и SHOW VARIABLES покажет -1.

23.2.3. Конфигурация Performance Schema во время работы

Таблицы установки Performance Schema содержат информацию о контролирующей конфигурации:

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
                 WHERE TABLE_SCHEMA = 'performance_schema' AND
                 TABLE_NAME LIKE 'setup%';
+-------------------+
| TABLE_NAME        |
+-------------------+
| setup_actors      |
| setup_consumers   |
| setup_instruments |
| setup_objects     |
| setup_timers      |
+-------------------+

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

Чтобы видеть, какие таймеры событий выбраны, запросите setup_timers:

mysql> SELECT * FROM setup_timers;
+-------------+-------------+
| NAME        | TIMER_NAME  |
+-------------+-------------+
| idle        | MICROSECOND |
| wait        | CYCLE       |
| stage       | NANOSECOND  |
| statement   | NANOSECOND  |
| transaction | NANOSECOND  |
+-------------+-------------+

NAME указывает на тип инструмента, к которому таймер применяется, а TIMER_NAME указывает, какой таймер относится к тем инструментам. Таймер относится к инструментам, где их имя начинается с компонента, соответствующего NAME.

Чтобы изменить таймер, обновите NAME. Например, чтобы использовать таймер NANOSECOND для wait:

mysql> UPDATE setup_timers SET TIMER_NAME = 'NANOSECOND'
                 WHERE NAME = 'wait';
mysql> SELECT * FROM setup_timers;
+-------------+-------------+
| NAME        | TIMER_NAME  |
+-------------+-------------+
| idle        | MICROSECOND |
| wait        | NANOSECOND  |
| stage       | NANOSECOND  |
| statement   | NANOSECOND  |
| transaction | NANOSECOND  |
+-------------+-------------+

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

Если есть изменения конфигурации Performance Schema, которые должны быть произведены во время выполнения, используя запросы SQL, и Вы хотели бы, чтобы эти изменения вступили в силу каждый раз, когда сервер запускается, поместите эти запросы в файл и запускайте сервер с опцией --init-file= file_name. Эта стратегия может также быть полезной, если у Вас есть много контрольных конфигураций, каждая чтобы произвести различный вид контроля. Поместите запросы для каждой контрольной конфигурации в их собственный файл и определите соответствующий файл как параметр --init-file, когда Вы запускаете сервер.

23.2.3.1. Синхронизация событий Performance Schema

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

Таймеры Performance Schema

Две таблицы Performance Schema предоставляют информацию о таймере:

  • performance_timers перечисляет доступные таймеры и их характеристики.

  • setup_timers указывает, какие таймеры используются для каких инструментов.

Каждая строка таймера в setup_timers должна обратиться к одному из таймеров, перечисленных в performance_timers .

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

mysql> SELECT * FROM performance_timers;
+-------------+-----------------+------------------+----------------+
| TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+-------------+-----------------+------------------+----------------+
| CYCLE       |      2389029850 |                1 |    72          |
| NANOSECOND  |      1000000000 |                1 |   112          |
| MICROSECOND |         1000000 |                1 |   136          |
| MILLISECOND |            1036 |                1 |   168          |
| TICK        |             105 |                1 |  2416          |
+-------------+-----------------+------------------+----------------+

У столбцов есть эти значения:

  • TIMER_NAME показывает названия доступных таймеров. CYCLE обращается к таймеру, который основан на счетчике цикла центрального процессора. Вы можете использовать таймеры в setup_timers, которые не имеют NULL в других столбцах. Если значения, связанные с данным именем таймера, NULL, этот таймер не поддержан на Вашей платформе.

  • TIMER_FREQUENCY указывает на число модулей таймера в секунду. Для счетчика циклов частота вообще связана со скоростью центрального процессора. Показанное значение было получено на системе 2.4GHz. Другие таймеры основаны на фиксированных долях секунд. Для TICK частота может изменяться платформой (например, некоторые используют 100 tick/секунду, другие 1000 tick/секунду).
  • TIMER_RESOLUTION указывает на число модулей таймера, которыми таймер оценивает увеличение за один раз. Если у таймера есть разрешение 10, его значение увеличивается на 10 каждый раз.
  • TIMER_OVERHEAD минимальное число циклов, чтобы получить одну синхронизацию с данным таймером. Издержки на событие являются удвоенным значением, выведенным на экран, потому что таймер вызван в начале и в конце.

Чтобы видеть, который таймеры работают или изменить таймеры, получите доступ к таблице setup_timers :

mysql> SELECT * FROM setup_timers;
+-------------+-------------+
| NAME        | TIMER_NAME  |
+-------------+-------------+
| idle        | MICROSECOND |
| wait        | CYCLE       |
| stage       | NANOSECOND  |
| statement   | NANOSECOND  |
| transaction | NANOSECOND  |
+-------------+-------------+

mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'
                 WHERE NAME = 'idle';
mysql> SELECT * FROM setup_timers;
+-------------+-------------+
| NAME        | TIMER_NAME  |
+-------------+-------------+
| idle        | MICROSECOND |
| wait        | CYCLE       |
| stage       | NANOSECOND  |
| statement   | NANOSECOND  |
| transaction | NANOSECOND  |
+-------------+-------------+

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

Для событий ожидания самый важный критерий это уменьшение издержек, таким образом использование таймера CYCLE является лучшим.

Время, которое запрос (или этап) занимает, чтобы выполниться, находится в общих порядках величины, больше чем время, которое требуется, чтобы выполнить только ожидание. Для запросов времени самым важным критерием должна быть точная мера, которая не затронута изменениями в частоте процессора, таким образом использование таймера, который не основан на циклах, является лучшим. Таймер по умолчанию для запросов NANOSECOND. Дополнительные издержки по сравнению с таймером CYCLE не являются существенными, потому что являются порядком величин меньше по сравнению со временем центрального процессора, используемым, чтобы выполнить запрос непосредственно. Использование таймера CYCLE не обладает никаким преимуществом здесь, только недостатками.

Точность, предлагаемая счетчиком цикла, зависит от скорости процессора. Если процессор достигает 1 ГГц (один миллиард циклов/секунду) или выше, счетчик цикла поставляет точность наносекунды. Использование счетчика цикла намного более дешево, чем получение фактического времени суток. Например, стандартная функция gettimeofday() может взять сотни циклов, что является недопустимыми издержками для того, что может произойти тысячи или миллионы раз в секунду.

У счетчиков цикла также есть недостатки:

  • Конечные пользователи ожидают видеть синхронизации в модулях стенных часов такие, как доли секунды. Преобразование из циклов в доли секунд может быть дорогим. Поэтому преобразование быстрая и довольно грубая работа умножения.

  • Уровень цикла процессора мог бы измениться, как тогда, когда ноутбук входит в сберегающий режим или когда центральный процессор замедляется, чтобы уменьшить температуру. Если уровень цикла процессора колеблется, преобразование циклов в модули в реальном времени подвергается ошибке.
  • Счетчики цикла могли бы быть ненадежными или недоступными в зависимости от процессора или операционной системы. Например, на Pentium есть инструкция RDTSC (ассемблер, а не инструкция C) и для операционной системы теоретически возможно препятствовать тому, чтобы программы пользовательского режима использовали это.
  • Некоторые детали процессора, не связанные с выполнением или синхронизацией, могли бы вызвать противоречия до 1000 циклов.

MySQL работает со счетчиками цикла на x386 (Windows, OS X, Linux, Solaris и другие разновидности Unix), PowerPC и IA-64.

Представление таймера Performance Schema в событиях

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

Таблица setup_instruments имеет столбец ENABLED, чтобы указать на инструменты, для которых можно собрать события. У таблицы также есть столбец TIMED, чтобы указать, какие инструменты рассчитаны. Если инструмент не включен, он не производит событий. Если включенный инструмент не рассчитан, события, произведенные инструментом, имеют NULL для значений таймера TIMER_START, TIMER_END и TIMER_WAIT. Это в свою очередь заставляет проигнорировать те значения, вычисляя сумму, минимум, максимум и средние временные оценки в сводных таблицах.

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

Модификации таблицы setup_timers применяются немедленно. События, уже происходящие, могут использовать оригинальный таймер в течение времени начала и новый таймер в течение времени окончания. Чтобы избежать непредсказуемых результатов после того, как Вы производите изменения таймера, надо использовать TRUNCATE TABLE, чтобы сбрасывать статистику Performance Schema.

Базовая линия таймера (нулевое время) происходит при инициализации Performance Schema во время запуска сервера. Значения TIMER_START и TIMER_END в событиях представляют пикосекунды, начиная с базовой линии. Значения TIMER_WAIT указывают продолжительности в пикосекундах.

Значения пикосекунды в событиях приблизительны. Их точность подвергается обычным формам ошибки, связанной с преобразованием от одного модуля до другого. Если таймер CYCLE используется, и уровень процессора изменяется, мог бы быть дрейф. По этим причинам неразумно смотреть на значение TIMER_START как на точную меру времени, начиная с запуска сервера. С другой стороны, разумно использовать TIMER_START или TIMER_WAIT в ORDER BY, чтобы упорядочить события по времени запуска или продолжительности.

У выбора пикосекунд в событиях, а не таких значений, как микросекунды есть исполнительное основание. Одна цель выполнения состояла в том, чтобы показать результаты в однородной единице измерения времени, независимо от таймера. В идеальном мире эта единица измерения времени была бы похожа на модуль стенных часов и была бы разумно точна, другими словами, микросекунды. Но преобразовать циклы или наносекунды к микросекундам, было бы необходимо выполнить деление для каждой инструментовки. Деление дорого на многих платформах. Умножение не дорого, так что оно и используется. Поэтому, единица измерения времени целое число, полученное из максимально возможного TIMER_FREQUENCY, используя множитель, достаточно большой, чтобы гарантировать, что нет никакой крупной потери точности. Результат состоит в том, что единица измерения времени пикосекунда . Эта точность является поддельной, но решение минимизирует издержки.

В то время как ожидание, этап, запрос или операционный случай выполняются, соответствующие таблицы текущих событий выводят на экран информацию о синхронизации текущих событий:

events_waits_current
events_stages_current
events_statements_current
events_transactions_current

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

  • TIMER_START заполнен.

  • TIMER_END заполнен текущим значением таймера.
  • TIMER_WAIT заполнен временем, прошедшим до сих пор (TIMER_END-TIMER_START).

События, которые еще не завершились, имеют значение END_EVENT_ID NULL. Чтобы оценить прошедшее время для случая, используйте столбец TIMER_WAIT. Поэтому, чтобы идентифицировать события, которые еще не завершились и заняли больше времени, чем N пикосекунд к настоящему времени, приложения могут использовать это выражение в запросах:

WHERE END_EVENT_ID IS NULL AND TIMER_WAIT > N

Идентификация событий как только описано предполагает, что соответствующие инструменты имеют ENABLED и TIMED установленные в YES, а соответствующие потребители включены.

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

События обработаны способом производителя/потребителя:

  • Инструментованный код производит события, которые будут собраны. Таблица setup_instruments приводит инструменты, для которых могут быть собраны события, включены ли они и (для включенных инструментов), собирать ли информацию синхронизации:

    mysql> SELECT * FROM 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 обеспечивает наиболее каноническую форму управления производством событий. Чтобы далее усовершенствовать производство событий, основанное на типе объекта или проверяемого потока, другие таблицы могут использоваться как описано в разделе 23.2.3.3.

  • Таблицы Performance Schema это места назначения для событий и потребители. Таблица setup_consumers приводит типы потребителей, в которые можно послать информацию о событии и включены ли они:
    mysql> SELECT * FROM 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, чтобы исследовать исполнительную проблему, когда ограничения использования предварительной фильтрации неизвестны заранее.

Следующие разделы обеспечивают больше деталей о предварительной фильтрации и обеспечивают направления для того, чтобы назвать инструменты или потребителей в фильтрации операций. Для информации о написании запросов, чтобы получить информацию (постфильтрация) см. раздел 23.3.

23.2.3.3. Предварительная фильтрация событий

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

  • Чтобы сконфигурировать предварительную фильтрацию на этапе производителя, несколько таблиц могут использоваться:

    • setup_instruments указывает, какие инструменты доступны. Инструмент, отключенный в этой таблице, не производит событий независимо от содержания других связанных с производством таблиц. Инструменту, включенному в этой таблице, разрешают произвести события, согласно содержанию других таблиц.

    • setup_objects контролирует особые таблицы Performance Schema и хранит объекты программы.
    • threads указывает, включен ли контроль для каждого потока сервера.
    • setup_actors определяет начальное контрольное состояние для новых потоков переднего плана.

  • Чтобы сконфигурировать предварительную фильтрацию на потребительском этапе, измените таблицу setup_consumers. Это определяет места назначения, в которые посылают события. Если данный случай не пошлют ни к какому месту назначения (то есть, он не будет потребляться), Performance Schema не производит его.

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

Когда Вы изменяете контролирующую конфигурацию, Performance Schema не сбрасывает таблицы истории. События, уже собранные, остаются в текущих событиях и таблицах истории пока не перемещены более новыми событиями. Если Вы отключаете инструменты, Вы, возможно, должны были бы ждать некоторое время прежде, чем события для них перемещены более новыми мероприятиями. Альтернативно, можно использовать TRUNCATE TABLE, чтобы освободить таблицы истории.

После произведения изменений инструментовки Вы могли бы хотеть усечь сводные таблицы. Вообще, эффект состоит в том, чтобы сбросить сводные столбцы к 0 или NULL, а не удалить строки. Это могло бы быть полезно, например, после того, как Вы произвели изменение конфигурации во время выполнения. Исключения к этому поведению усечения отмечены в отдельных разделах сводной таблицы.

Следующие разделы описывают, как использовать определенные таблицы, чтобы управлять предварительной фильтрацией Performance Schema.

23.2.3.4. Предварительная фильтрация по инструменту

Таблица setup_instruments приводит доступные инструменты:

mysql> SELECT * FROM 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   |
...
| wait/synch/rwlock/sql/LOCK_grant                  | YES     | YES   |
| wait/synch/rwlock/sql/LOGGER::LOCK_logger         | YES     | YES   |
| wait/synch/rwlock/sql/LOCK_sys_init_connect       | YES     | YES   |
| wait/synch/rwlock/sql/LOCK_sys_init_slave         | YES     | YES   |
...
| wait/io/file/sql/binlog                           | YES     | YES   |
| wait/io/file/sql/binlog_index                     | YES     | YES   |
| wait/io/file/sql/casetest                         | YES     | YES   |
| wait/io/file/sql/dbopt                            | YES     | YES   |
...

Чтобы управлять, включен ли инструмент, устанавливайте столбец ENABLED в YES или NO. Чтобы сконфигурировать, собирать ли информацию синхронизации для включенного инструмента, установите TIMED в YES или NO. Установка TIMED затрагивает табличное содержание Performance Schema как описано в разделе 23.2.3.1.

Модификации большинства строк setup_instruments действуют немедленно. Для некоторых инструментов модификации эффективны только при запуске сервера, изменение их во время выполнения не имеет никакого эффекта. Это затрагивает прежде всего mutexes, условия и rwlocks в сервере, хотя могут быть другие инструменты, для которых это истина.

Таблица setup_instruments обеспечивает наиболее каноническую форму управления производством событий. Чтобы далее усовершенствовать производство событий, основанное на типе объекта или проверяемого потока, другие таблицы могут использоваться как описано в разделе 23.2.3.3.

Следующие примеры демонстрируют возможные операции на setup_instruments . Эти изменения, как другие операции перед фильтрацией, затрагивают всех пользователей. Некоторые из этих запросов используют оператор LIKE и инструмент соответствия образца. Для дополнительной информации об определении образцов, чтобы выбрать инструменты см. раздел 23.2.3.9.

  • Отключите все инструменты:

    mysql> UPDATE setup_instruments SET ENABLED = 'NO';
    

    Теперь никакие события не будут собраны.

  • Отключите все инструменты файла, добавляя их к текущему набору отключенных инструментов:
    mysql> UPDATE setup_instruments SET ENABLED = 'NO'
                     WHERE NAME LIKE 'wait/io/file/%';
    
  • Отключите только инструменты файла, включите все другие инструменты:
    mysql> UPDATE setup_instruments
              SET ENABLED = IF(NAME LIKE 'wait/io/file/%', 'NO', 'YES');
    
  • Включите все, кроме инструментов в библиотеке mysys:
    mysql> UPDATE setup_instruments SET ENABLED = CASE
                     WHEN NAME LIKE '%/mysys/%' THEN 'YES' ELSE 'NO' END;
    
  • Отключите определенный инструмент:
    mysql> UPDATE setup_instruments SET ENABLED = 'NO'
                     WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';
    
  • Переключите статус инструмента flip:
    mysql> UPDATE setup_instruments
                     SET ENABLED = IF(ENABLED = 'YES','NO','YES')
                     WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';
    
  • Отключите синхронизацию для всех событий:
    mysql> UPDATE setup_instruments SET TIMED = 'NO';
    

23.2.3.5. Предварительная фильтрация по объекту

Таблица setup_objects управляет, контролирует ли Performance Schema особую таблицу и хранение объектов программы. Начальное содержимое setup_objects похоже на это:

mysql> SELECT * FROM setup_objects;
+-------------+--------------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME | ENABLED | TIMED |
+-------------+--------------------+-------------+---------+-------+
| EVENT       | mysql              | %           | NO      | NO    |
| EVENT       | performance_schema | %           | NO      | NO    |
| EVENT       | information_schema | %           | NO      | NO    |
| EVENT       | %                  | %           | YES     | YES   |
| FUNCTION    | mysql              | %           | NO      | NO    |
| FUNCTION    | performance_schema | %           | NO      | NO    |
| FUNCTION    | information_schema | %           | NO      | NO    |
| FUNCTION    | %                  | %           | YES     | YES   |
| PROCEDURE   | mysql              | %           | NO      | NO    |
| PROCEDURE   | performance_schema | %           | NO      | NO    |
| PROCEDURE   | information_schema | %           | NO      | NO    |
| PROCEDURE   | %                  | %           | YES     | YES   |
| TABLE       | mysql              | %           | NO      | NO    |
| TABLE       | performance_schema | %           | NO      | NO    |
| TABLE       | information_schema | %           | NO      | NO    |
| TABLE       | %                  | %           | YES     | YES   |
| TRIGGER     | mysql              | %           | NO      | NO    |
| TRIGGER     | performance_schema | %           | NO      | NO    |
| TRIGGER     | information_schema | %           | NO      | NO    |
| TRIGGER     | %                  | %           | YES     | YES   |
+-------------+--------------------+-------------+---------+-------+

Модификации setup_objects вступают в силу немедленно.

Столбец OBJECT_TYPE указывает на тип объекта, к которому применяется строка. TABLE фильтрует табличные события ввода/вывода (инструмент wait/io/table/sql/handler) и события блокировки (инструментwait/lock/table/sql/handler).

Столбцы OBJECT_SCHEMA и OBJECT_NAME должны содержать буквальную схему или название объекта или '%', чтобы соответствовать любому имени.

Столбец ENABLED указывает, проверены ли соответствующие объекты, а TIMED указывает, собирать ли информацию синхронизации. Установка TIMED затрагивает табличное содержание Performance Schema как описано в разделе 23.2.3.1.

Эффект конфигурации объекта по умолчанию состоит в том, чтобы инструментовать все объекты кроме тех, которые в базах данных mysql, INFORMATION_SCHEMA и performance_schema. Таблицы в INFORMATION_SCHEMA не инструментованы независимо от содержания setup_objects: строка для information_schema.% просто делает это значение по умолчанию явным.

Когда Performance Schema проверяет на соответствие в setup_objects, это пытается найти более определенные соответствия сначала. Для строк, которые соответствуют данному OBJECT_TYPE, Performance Schema проверяет строки в этом порядке:

  • Строки с OBJECT_SCHEMA='literal' и OBJECT_NAME='literal'.

  • Строки с OBJECT_SCHEMA='literal' и OBJECT_NAME='%'.
  • Строки с OBJECT_SCHEMA='%' и OBJECT_NAME='%'.

Например, с таблицей db1.t1 Performance Schema смотрит строки для TABLE для 'db1' и 't1', потом для 'db1' и '%', а уже потом для '%' и '%'. Порядок, в котором соответствие происходит такой, потому что различное соответствующие строки setup_objects могут иметь отличающиеся значения ENABLED и TIMED.

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

  • Для таблиц, которые соответствуют строке в setup_objects, табличные инструменты производят события только, если ENABLED YES в setup_instruments и setup_objects.

  • Значения TIMED в этих двух таблицах объединены так, чтобы информация синхронизации была собрана только, когда оба значения YES.

Для хранимых объектов программы Performance Schema берет столбцы ENABLED и TIMED непосредственно из строки setup_objects. Нет никакого объединения значений с setup_instruments .

Предположите, что setup_objects содержит следующие строки TABLE, которые относятся к db1, db2 и db3:

+-------------+---------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED |
+-------------+---------------+-------------+---------+-------+
| TABLE       | db1           | t1          | YES     | YES   |
| TABLE       | db1           | t2          | NO      | NO    |
| TABLE       | db2           | %           | YES     | YES   |
| TABLE       | db3           | %           | NO      | NO    |
| TABLE       | %             | %           | YES     | YES   |
+-------------+---------------+-------------+---------+-------+

Если связанный с объектом инструмент в setup_instruments имеет ENABLED NO, события для объекта не отслеживаются. Если ENABLED YES, контроль событий происходит согласно значению ENABLED в соответствующей строке setup_objects:

  • События db1.t1 отслеживаются.

  • События db1.t2 не отслеживаются.
  • События db2.t3 отслеживаются.
  • События db3.t4 не отслеживаются.
  • События db4.t5 отслеживаются.

Подобная логика просит объединения столбцов TIMED из setup_instruments и setup_objects , чтобы определить, собирать ли информацию синхронизации событий.

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

23.2.3.6. Предварительная фильтрация по потоку

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

  • Потребитель thread_instrumentation в setup_consumers должен быть YES.

  • Столбец threads.INSTRUMENTED должен быть YES.
  • Контроль происходит только для событий потока, произведенных из инструментов, которые включены в setup_instruments .

Таблица threads также показывает для каждого потока сервера, выполнить ли журналирование исторического события. Это включает ожидание, подготовку, запрос и операционное журналирование событий для этих таблиц:

events_waits_history
events_waits_history_long
events_stages_history
events_stages_history_long
events_statements_history
events_statements_history_long
events_transactions_history
events_transactions_history_long

Для журналирования исторического события эти вещи должны быть истиной:

  • Соответствующие связанные с историей потребители в setup_consumers должны быть включены. Например, случай ожидания, протоколируемый в events_waits_history и events_waits_history_long требует соответствующих потребителей events_waits_history и events_waits_history_long со статусом YES.

  • Столбец threads.HISTORY должен быть YES.
  • Журналирование происходит только для событий потока, произведенных из инструментов, которые включены в setup_instruments .

Для потоков переднего плана (следующих из соединений клиента), начальные значения столбцов INSTRUMENTED и HISTORY в строках таблицы threads определены тем, соответствует ли учетная запись пользователя, связанная с потоком, какой-либо строке в setup_actors. Значения прибывают из столбцов ENABLED и HISTORY соответствующих строк setup_actors.

Для фоновых потоков нет никакого связанного пользователя. INSTRUMENTED и HISTORY YES по умолчанию и setup_actors не проверяется.

Стартовое содержание setup_actors похоже на это:

mysql> SELECT * FROM setup_actors;
+------+------+------+---------+---------+
| HOST | USER | ROLE | ENABLED | HISTORY |
+------+------+------+---------+---------+
| %    | %    | %    | YES     | YES     |
+------+------+------+---------+---------+

Столбцы HOST и USER должны содержать буквальный узел или имя пользователя, или '%', чтобы соответствовать любому имени.

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

Когда Performance Schema проверяет на соответствие каждый новый поток переднего плана в setup_actors, это пытается найти более определенные соответствия сначала, используя столбцы USER и HOST (ROLE не использован):

  • Строки с USER='literal' и HOST='literal'.

  • Строки с USER='literal' и HOST='%'.
  • Строки с USER='%' и HOST='literal'.
  • Строки с USER='%' и HOST='%'.

Порядок, в котором соответствие происходит таков, потому что различные соответствующие строки setup_actors могут иметь отличающиеся USER и HOST. Это позволяет инструментовать и журналировать события, которые будут применены выборочно на основе узла, пользователя или учетной записи (комбинация пользователя и узла), исходя из значения столбцов: ENABLED и HISTORY:

  • Когда лучшее соответствие строка с ENABLED=YES, значение INSTRUMENTED для потока становится YES. Когда лучшее соответствие строка с HISTORY=YES, HISTORY для потока становится YES.

  • Когда лучшее соответствие строка с ENABLED=NO, INSTRUMENTED для потока становится NO. Когда лучшее соответствие строка с HISTORY=NO, HISTORY для потока становится NO.
  • Когда никакое соответствие не найдено, INSTRUMENTED и HISTORY для потока становятся NO.

Столбцы ENABLED и HISTORY в строках setup_actors могут быть установлены в YES или NO независимо друг от друга. Это означает, что Вы можете включить инструментовку отдельно от того, собираете ли Вы исторические события.

По умолчанию контроль и набор исторического события включен для всех новых потоков переднего плана потому, что setup_actors первоначально содержит строку с '%' для HOST и USER. Чтобы выполнить более ограниченное соответствие, например, позволить контролировать только для некоторых потоков переднего плана, Вы должны изменить эту строку, потому что это соответствует любому соединению, и добавить строки для более определенной комбинации HOST/USER.

Предположите, что Вы изменяете setup_actors следующим образом:

UPDATE setup_actors SET ENABLED = 'NO', HISTORY = 'NO'
       WHERE HOST = '%' AND USER = '%';
INSERT INTO setup_actors (HOST,USER,ROLE,ENABLED,HISTORY)
       VALUES('localhost','joe','%','YES','YES');
INSERT INTO setup_actors (HOST,USER,ROLE,ENABLED,HISTORY)
       VALUES('hosta.example.com','joe','%','YES','NO');
INSERT INTO setup_actors (HOST,USER,ROLE,ENABLED,HISTORY)
       VALUES('%','sam','%','NO','YES');

UPDATE изменяет соответствие по умолчанию, чтобы отключить набор исторического события и инструментовку. INSERT добавляют строки для более определенных соответствий.

Теперь Performance Schema определяет, как установить значения INSTRUMENTED и HISTORY для потока нового соединения следующим образом:

  • Если joe соединяется с локального хоста, соединение соответствует первой вставленной строке. INSTRUMENTED и HISTORY для потока становятся YES.

  • Если joe соединяется с hosta.example.com, соединение соответствует второй вставленной строке. INSTRUMENTED для потока становится YES, а HISTORY NO.
  • Если joe соединяется с любого другого узла, это не идет ни в какое сравнение. INSTRUMENTED и HISTORY для потока становятся NO.
  • Если sam соединяется с любого узла, соединение соответствует третей вставленной строке. INSTRUMENTED для потока становится NO, а HISTORY YES.
  • Для любого другого соединения строки с HOST и USER соответствуют '%'. Эта строка теперь имеет ENABLED и HISTORY NO, так что INSTRUMENTED и HISTORY для потока становятся NO.

Модификации setup_actors влияют только на потоки переднего плана, созданные после модификации, а не на существующие потоки. Чтобы затронуть существующие потоки, измените INSTRUMENTED и HISTORY строках таблицы threads.

23.2.3.7. Предварительная фильтрация по потребителю

setup_consumers приводит доступные потребительские типы и то, которые включены:

mysql> SELECT * FROM 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     |
+----------------------------------+---------+

Измените setup_consumers , чтобы затронуть предварительную фильтрацию в потребителе и определить места назначения, в которые посылают события. Чтобы включить или отключить потребителя, установите ENABLED в YES или NO.

Модификации setup_consumers срабатывают немедленно.

Если Вы отключаете потребителя, сервер не тратит времени на поддержание места назначения для этого потребителя. Например, если Вы не заботитесь об информации об историческом событии, отключите потребителей истории:

mysql> UPDATE setup_consumers SET ENABLED = 'NO' WHERE NAME
                 LIKE '%history%';

Потребительские настройки в setup_consumers имеют иерархию. Следующие принципы применяются:

  • Места назначения, связанные с потребителем, не получают событий, если Performance Schema не проверяет потребителя.

  • Потребитель проверен, только если все потребители, от которых он зависит (если такие есть), включены.
  • Если потребитель не проверен, или проверен, но отключен, другие потребители, которые зависят от него, не проверены.
  • У зависимых потребителей могут быть свои собственные зависимые потребители.
  • Если случай не послан никакому месту назначения, Performance Schema не производит его.

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

Глобальные и потребители потока

  • global_instrumentation потребитель высшего уровня. Если global_instrumentation NO, это отключает глобальную инструментовку. Все другие настройки более низкого уровня и не проверены, не имеет значения, во что они установлены. Нет глобальной или поточной информацим о потоке, и никакие одиночные события не собраны в таблицах истории событий или текущих событиях. Если global_instrumentation YES, Performance Schema поддерживает информацию для глобальных состояний, а также проверяет потребителей thread_instrumentation.

  • thread_instrumentation проверен только, если global_instrumentation YES. Иначе, если thread_instrumentation NO, это отключает определенную для потока инструментовку, и все настройки низшего уровня проигнорированы. Никакая информация не поддержана для потока, и никакие одиночные события не собраны в таблицах истории событий или текущих событиях. Если thread_instrumentation YES, Performance Schema поддерживает определенную для потока информацию, а также проверяет events_xxx_current.

Потребители событий ожидания

Эти потребители требуют установки обоих global_instrumentation и thread_instrumentation в YES или они не проверены. Если проверены, они действуют следующим образом:

  • events_waits_current, если NO, отключает сбор индивидуальных событий ожидания в таблице events_waits_current . Если YES, это включает сбор событий и Performance Schema проверяет events_waits_history и events_waits_history_long.

  • events_waits_history не проверен, если event_waits_current NO. Иначе events_waits_history NO или YES отключает или включает сбор событий в таблице events_waits_history .
  • events_waits_history_long не проверен, если event_waits_current NO. Иначе events_waits_history_long NO или YES отключает или включает сбор событий в таблице events_waits_history_long.

Потребители событий этапа

Эти потребители требуют global_instrumentation и thread_instrumentation в YES или они не проверены. Если проверены, действуют следующим образом:

  • events_stages_current, если NO, отключает сбор отдельных событий этапа в таблице events_stages_current . Если YES, это включает сбор этапов событий, и Performance Schema проверяет events_stages_history и events_stages_history_long.

  • events_stages_history не проверен, если event_stages_current NO. Иначе events_stages_history NO или YES отключает или включает сбор событий этапа в events_stages_history .
  • events_stages_history_long не проверен, если event_stages_current NO. Иначе events_stages_history_long NO или YES отключает или включает сбор событий этапа в events_stages_history_long.

Потребители событий запроса

Эти потребители требуют global_instrumentation и thread_instrumentation в YES или они не проверены. Если проверены, действуют следующим образом:

  • events_statements_current, если NO, отключает сбор отдельных событий запроса в таблице events_statements_current. Если YES, это включает сбор запросов событий, и Performance Schema проверяет events_statements_history и events_statements_history_long.

  • events_statements_history не проверен, если events_statements_current NO. Иначе events_statements_history NO или YES отключает или включает сбор событий запроса в таблице events_statements_history.
  • events_statements_history_long не проверен, если events_statements_current NO. Иначе events_statements_history_long NO или YES отключает или включает сбор событий запроса в таблице events_statements_history_long.

Операционные потребители событий

Эти потребители требуют global_instrumentation и thread_instrumentation YES или они не проверены. Если проверены, они действуют следующим образом:

  • events_transactions_current, если NO, отключает сбор отдельных операционных событий в таблице events_transactions_current. Если YES, это включает сбор операционных событий, и Performance Schema проверяет events_transactions_history и events_transactions_history_long.

  • events_transactions_history не проверен, если events_transactions_current NO. Иначе events_transactions_history NO или YES отключает или включает сбор операционных событий в таблице events_transactions_history.
  • events_transactions_history_long не проверен, если events_transactions_current NO. Иначе events_transactions_history_long NO или YES отключает или включает сбор операционных событий в таблице events_transactions_history_long.

Потребитель обзора запросов

Этот потребитель требует global_instrumentation YES или это не проверено. Нет никакой зависимости от потребителей событий запросов, таким образом, Вы можете получить статистику обзоров, не имея необходимости собирать статистические данные в events_statements_current, что выгодно с точки зрения издержек. Наоборот, Вы можете вложить детализированные запросы events_statements_current без обзоров (столбцы DIGEST и DIGEST_TEXT должны быть NULL).

23.2.3.8. Потребительские конфигурации в качестве примера

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

Описания конфигурации происходят в порядке увеличивающейся функциональности. Если Вы не нуждаетесь в информации, предоставленной, включая настройками низшего уровня, отключите их, и Performance Schema выполнит меньше кода от Вашего имени.

Таблица setup_consumers содержит следующую иерархию значений:

global_instrumentation
 thread_instrumentation
   events_waits_current
 events_waits_history
 events_waits_history_long
   events_stages_current
 events_stages_history
 events_stages_history_long
   events_statements_current
 events_statements_history
 events_statements_history_long
   events_transactions_current
 events_transactions_history
 events_transactions_history_long
 statements_digest

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

Если данный потребитель устанавливает NO, Performance Schema отключает инструментовку, связанную с потребителем, и игнорирует все настройки низшего уровня. Если данная установка YES, Performance Schema включает инструментовку, связанную с этим, и проверяет настройки на следующем самом низком уровне. Для описания правил для каждого потребителя см. раздел 23.2.3.7.

Например, если global_instrumentation включен, thread_instrumentation проверен. Если thread_instrumentation включен, потребители events_xxx_current проверены. Если из них events_waits_current включен, events_waits_history и events_waits_history_long проверены.

Каждое из следующих описаний конфигурации указывает, какие элементы установки проверки Performance Schema выводят таблицы, которые она поддерживает (то есть, для которых таблиц она собирает информацию).

Никакой инструментовки

Состояние конфигурации сервера:

mysql> SELECT * FROM setup_consumers;
+---------------------------+---------+
| NAME                      | ENABLED |
+---------------------------+---------+
| global_instrumentation    | NO      |
...
+---------------------------+---------+

В этой конфигурации ничто не инструментовано.

Элементы установки проверяют:

Выходные таблицы поддержаны:

  • Нет.

Только глобальная инструментовка

Состояние конфигурации сервера:

mysql> SELECT * FROM setup_consumers;
+---------------------------+---------+
| NAME                      | ENABLED |
+---------------------------+---------+
| global_instrumentation    | YES     |
| thread_instrumentation    | NO      |
...
+---------------------------+---------+

В этой конфигурации инструментовка поддержана только для глобальных состояний. Инструментовка потоков отключена.

Дополнительные проверенные элементы установки, относительно предыдущей конфигурации:

Дополнительные выходные таблицы, относительно предыдущей конфигурации:

Инструментовка глобальная и потока

Состояние конфигурации сервера:

mysql> SELECT * FROM setup_consumers;
+----------------------------------+---------+
| NAME                             | ENABLED |
+----------------------------------+---------+
| global_instrumentation           | YES     |
| thread_instrumentation           | YES     |
| events_waits_current             | NO      |
...
| events_stages_current            | NO      |
...
| events_statements_current        | NO      |
...
| events_transactions_current      | NO      |
...
+----------------------------------+---------+

В этой конфигурации инструментовка поддержана глобально и для потоков. Никакие одиночные события не собраны в таблицах истории событий или текущих событиях.

Дополнительные проверенные элементы установки, относительно предыдущей конфигурации:

  • Таблица setup_consumers, потребители events_xxx _current, где xxx waits, stages, statements, transactions.

  • Таблица setup_actors .
  • Столбец threads.instrumented.

Дополнительные выходные поддержанные таблицы, относительно предыдущей конфигурации:

  • events_xxx_summary_by_yyy _by_event_name, где xxx waits, stages, statements, transactions, а yyy thread, user, host, account.

Инструментовка текущих событий, глобальная и потока

Состояние конфигурации сервера:

mysql> SELECT * FROM setup_consumers;
+----------------------------------+---------+
| NAME                             | ENABLED |
+----------------------------------+---------+
| global_instrumentation           | YES     |
| thread_instrumentation           | YES     |
| events_waits_current             | YES     |
| events_waits_history             | NO      |
| events_waits_history_long        | NO      |
| events_stages_current            | YES     |
| 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      | YES     |
| events_transactions_history      | YES     |
| events_transactions_history_long | NO      |
...
+----------------------------------+---------+

В этой конфигурации инструментовка поддержана глобально и для потока. Одиночные события собраны в таблице текущих событий, но не в таблицах истории событий.

Дополнительные проверенные элементы установки, относительно предыдущей конфигурации:

  • Потребители events_xxx_history, где xxx waits, stages, statements, transactions.

  • Потребители events_xxx_history_long, где xxx waits, stages, statements, transactions.

Дополнительные выходные поддержанные таблицы, относительно предыдущей конфигурации:

  • events_xxx_current, где xxx is waits, stages, statements, transactions.

Инструментовка текущих событий, стории событий, глобальная и потока

Предыдущая конфигурация не собирает историю событий потому, что потребители events_xxx_history и events_xxx_history_long отключены. Эти потребители можно включить отдельно или вместе, чтобы собрать историю событий для потока, глобально или обоими способами.

Эта конфигурация собирает историю событий для потока, но не глобально:

mysql> SELECT * FROM setup_consumers;
+----------------------------------+---------+
| NAME                             | ENABLED |
+----------------------------------+---------+
| global_instrumentation           | YES     |
| thread_instrumentation           | YES     |
| events_waits_current             | YES     |
| events_waits_history             | YES     |
| events_waits_history_long        | NO      |
| events_stages_current            | YES     |
| events_stages_history            | YES     |
| events_stages_history_long       | 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_xxx_history, где xxx waits, stages, statements, transactions.

Эта конфигурация собирает историю событий глобально, но не для потока:

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

Таблицы истории событий для этой конфигурации:

  • events_xxx_history_long, где xxx waits, stages, statements, transactions.

Эта конфигурация собирает историю событий для потока и глобально:

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

Таблицы истории событий для этой конфигурации:

  • events_xxx_history, где xxx waits, stages, statements, transactions.

  • events_xxx_history_long, где xxx waits, stages, statements, transactions.

23.2.3.9. Обозначение инструментов или потребителей для операций фильтрации

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

mysql> UPDATE setup_instruments SET ENABLED = 'NO'
                 WHERE NAME = 'wait/synch/mutex/myisammrg/MYRG_INFO::mutex';
mysql> UPDATE setup_consumers
                 SET ENABLED = 'NO' WHERE NAME = 'events_waits_current';

Чтобы определить группу инструментов или потребителей, используйте образец, который соответствует членам группы:

mysql> UPDATE setup_instruments SET ENABLED = 'NO'
                 WHERE NAME LIKE 'wait/synch/mutex/%';
mysql> UPDATE setup_consumers SET ENABLED = 'NO'
                 WHERE NAME LIKE '%history%';

Если Вы используете образец, это должно быть выбрано так, чтобы соответствовало всем элементам, представляющим интерес и никаким другим. Например, чтобы выбрать все инструменты ввода/вывода файла, лучше использовать образец, который включает всю инструментальную приставку имени:

... WHERE NAME LIKE 'wait/io/file/%';

Образец '%/file/%' будет соответствовать другим инструментам, у которых есть компонент '/file/' где угодно в имени. Еще менее подходящий образец '%file%', так как это будет соответствовать инструментам с 'file' где угодно в имени, например, wait/synch/mutex/sql/LOCK_des_key_file.

Чтобы проверить, какой инструмент или потребитель вызывают соответствие образцу, выполните простой тест:

mysql> SELECT NAME FROM setup_instruments
                 WHERE NAME LIKE 'pattern';
mysql> SELECT NAME FROM setup_consumers
                 WHERE NAME LIKE 'pattern';

23.2.3.10. Определение, что инструментовано

Всегда возможно определить то, что инструментует Performance Schema, проверяя setup_instruments . Например, чтобы видеть, какие связанные с файлом события инструментованы для механизма хранения InnoDB, используйте этот запрос:

mysql> SELECT * FROM setup_instruments
                   WHERE NAME LIKE 'wait/io/file/innodb/%';
+--------------------------------------+---------+-------+
| NAME                                 | ENABLED | TIMED |
+--------------------------------------+---------+-------+
| wait/io/file/innodb/innodb_data_file | YES     | YES   |
| wait/io/file/innodb/innodb_log_file  | YES     | YES   |
| wait/io/file/innodb/innodb_temp_file | YES     | YES   |
+--------------------------------------+---------+-------+

Исчерпывающее описание того, что инструментовано, не дано в этой документации, по нескольким причинам:

  • То, что инструментовано, является кодом сервера. Изменения этого кода часто происходят, что также затрагивает набор инструментов.

  • Непрактично перечислять все инструменты, потому что их сотни.
  • Как описано ранее, возможно узнать, запрашивая таблицу setup_instruments . Эта информация всегда современна для Вашей версии MySQL, а также включает инструментовку для плагинов, которые Вы, возможно, установили, не являющихся частью основного сервера. Они могут использоваться автоматизированными инструментами.

23.3. Запросы Performance Schema

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

В разделе 23.2.3.3 , пример показал, как предварительно фильтровать для инструментов файла. Если таблицы событий содержат информацию о файле и не о файле, постфильтрация другой способ видеть информацию только для событий файла. Добавьте WHERE к запросам, чтобы ограничить выбор событий соответственно:

mysql> SELECT THREAD_ID, NUMBER_OF_BYTES FROM events_waits_history
                 WHERE EVENT_NAME LIKE 'wait/io/file/%' AND
                 NUMBER_OF_BYTES IS NOT NULL;
+-----------+-----------------+
| THREAD_ID | NUMBER_OF_BYTES |
+-----------+-----------------+
|  11       |  66             |
|  11       |  47             |
|  11       | 139             |
|   5       |  24             |
|   5       | 834             |
+-----------+-----------------+

Большинство таблиц Performance Schema имеют индекс, который предоставляет оптимизатору доступ к планам выполнения кроме полного сканирования таблицы. Они также улучшают работу для связанных объектов, таких как представления sys schema, которые используют те таблицы. Для получения дополнительной информации см. раздел 9.2.5.

23.4. Соглашения о присвоении имен инструментам Performance Schema

Инструментальное имя состоит из последовательности компонентов, отделенных '/' Имена в качестве примера:

wait/io/file/myisam/log
wait/io/file/mysys/charset
wait/lock/table/sql/handler
wait/synch/cond/mysys/COND_alarm
wait/synch/cond/sql/BINLOG::update_cond
wait/synch/mutex/mysys/BITMAP_mutex
wait/synch/mutex/sql/LOCK_delete
wait/synch/rwlock/sql/Query_cache_query::lock
stage/sql/closing tables
stage/sql/Sorting result
statement/com/Execute
statement/com/Query
statement/sql/create_table
statement/sql/lock_tables
errors

У инструментального пространства имен есть подобная дереву структура. Компоненты инструментального имени слева направо обеспечивают прогрессию от более общего до более определенного. Число компонентов, которые имеет имя, зависит от типа инструмента.

Интерпретация данного компонента зависит от компонентов слева от этого. Например, myisam появляется в обоих из следующих имен, но myisam в первом имени связан с вводом/выводом файла, тогда как во втором это связано с инструментом синхронизации:

wait/io/file/myisam/log
wait/synch/cond/myisam/MI_SORT_INFO::cond

Инструментальные имена состоят из приставки со структурой, определенной выполнением Performance Schema и суффиксом, определенным разработчиком, осуществляющим инструментальный код. Высокоуровневый компонент инструментальной приставки указывает на тип инструмента. Этот компонент также определяет, который таймер событий в setup_timers относится к инструменту. Для части приставки инструментальных имен верхний уровень указывает на тип инструмента.

Часть суффикса инструментальных имен прибывает непосредственно из кода для инструментов. Суффиксы могут включать уровни, такие как:

  • Название главного компонента (модуль сервера такой, как myisam, innodb, mysys или sql) или имя плагина.

  • Название переменной в коде, в форме XXX (глобальная переменная) или CCC::MMM (член MMM класса CCC). Примеры: COND_thread_cache, THR_LOCK_myisam, BINLOG::LOCK_index.

Высокоуровневые инструментальные компоненты

  • idle: Инструментованный неактивный случай. У этого инструмента нет никаких дальнейших компонентов.

  • error: Инструментованный ошибочный случай. У этого инструмента нет никаких дальнейших компонентов.
  • memory: Инструментованное событие памяти.
  • stage: Инструментованное событие этапа.
  • statement: Инструментованное событие запроса.
  • transaction: Инструментованное событие транзакции. У этого инструмента нет никаких дальнейших компонентов.
  • wait: Инструментованное событие ожидания.

Неактивные инструментальные компоненты

Инструмент idle используется для неактивных событий, которые Performance Schema производит как обсуждено в описании столбца socket_instances.STATE в разделе 23.9.3.5.

Ошибочные инструментальные компоненты

Инструмент error указывает, собрать ли информацию для ошибок сервера и предупреждений. Этот инструмент включен по умолчанию. Столбец TIMED для строки error в setup_instruments является неподходящим, потому что информация синхронизации не собрана.

Инструментальные компоненты памяти

Большинство инструментов памяти отключено по умолчанию и может быть включено или отключено динамически, обновляя столбец ENABLED соответствующих инструментов в setup_instruments . У инструментов памяти есть названия формы memory/code_area/instrument_name , где code_area такое значение, как sql или myisam, а instrument_name инструментальная деталь.

Инструменты с приставкой memory/performance_schema/ показывают, сколько памяти выделено для внутренних буферов в Performance Schema. Инструменты memory/performance_schema/ встроены, всегда включаются, и не могут быть отключены при запуске или во время выполнения. Встроенные инструменты памяти выведены на экран только в таблице memory_summary_global_by_event_name.

Инструментальные компоненты этапа

У инструментов этапа есть названия формы stage/code_area/stage_name , где code_area такое значение, как sql или myisam, а stage_name указывает на этап обработки запроса, такой как Sorting result или Sending data. Этапы соответствуют статусам потока, выведенным на экран SHOW PROCESSLIST или видимым в INFORMATION_SCHEMA.PROCESSLIST .

Инструментальные Компоненты запроса

  • statement/abstract/*: Абстрактный инструмент для операций запроса. Абстрактные инструменты используются во время ранних стадий классификации запроса прежде, чем точный тип запроса будет известен, затем изменены на более определенный инструмент запроса, когда тип известен. Для описания этого процесса см. раздел 23.9.6.

  • statement/com: Инструментованная работа команды. У них есть соответствие имен COM_xxx (см. файлы mysql_com.h и sql/sql_parse.cc). Например, инструменты statement/com/Connect и statement/com/Init DB соответствуют командам COM_CONNECT и COM_INIT_DB.
  • statement/scheduler/event: Единственный инструмент, чтобы отследить все события, запущенные планировщиком событий. Этот инструмент играет роль, когда запланированный случай начинает выполняться.
  • statement/sp: Инструментованная внутренняя инструкция выполнена сохраненной программой. Например, инструменты statement/sp/cfetch и statement/sp/freturn применяются для получения курсора и возврата из функции.
  • statement/sql: Инструментованная работа запроса SQL. Например, инструменты statement/sql/create_db и statement/sql/select используются для CREATE DATABASE и SELECT.

Инструментальные компоненты ожидания

  • wait/io

    Инструментованная работа ввода/вывода.

    • wait/io/file

      Инструментованная работа ввода/вывода файла. Для файлов ожидание является временем ожидания завершения работы файла (например, вызов fwrite()). Из-за кэширования физический ввод/вывод файла на диске не может произойти в пределах этого требования.

    • wait/io/socket

      Инструментованная работа сокета. У инструментов сокета есть названия формы wait/io/socket/sql/socket_type. У сервера есть сокеты для каждого сетевого протокола, который он поддерживает. У инструментов, связанных с сокетами TCP/IP или соединений файла сокета Unix, есть значение socket_type server_tcpip_socket или server_unix_socket, соответственно. Когда сокет слушания обнаруживает соединение, сервер передает соединение с новым сокетом, которым управляет отдельный поток. У инструмента для нового потока соединения есть значение socket_type client_connection.

    • wait/io/table

      Инструментованная табличная работа ввода/вывода. Они включают доступы на уровне строки к постоянным базовым или временным таблицам. Операции, которые затрагивают строки, являются получением, вставками, обновлениями и удалениями. Для представления ожидание связано с базовыми таблицами, на которые ссылается представление.

      В отличие от большинства ожиданий, табличный ввод/вывод может включать другое ожидание. Например, табличный ввод/вывод мог бы включать ввод/вывод файла или операции памяти. Таким образом, events_waits_current для таблицы обычно имеет две строки.

      Некоторые операции строки могли бы вызвать многократный табличный ввод/вывод. Например, вставка могла бы активировать триггер, который вызывает обновление.

  • wait/lock

    Инструментованная работа блокировки.

    • wait/lock/table

      Инструментованная блокировка таблицы.

    • wait/lock/metadata/sql/mdl

      Инструментованные метаданные блокировки (отключены по умолчанию).

  • wait/synch

    Инструментованный объект синхронизации. Для объектов синхронизации время TIMER_WAIT включает количество заблокированное времени, потраченное пытаясь приобрести блокировку на объекте, если это было.

    • wait/synch/cond

      Условие используется одним потоком, чтобы сигнализировать другим потокам, что что-то, чего они ждали, произошло. Если единственный поток ждал условия, он может проснуться и возобновить выполнение. Если несколько потоков ждали, они могут все проснуться и конкурировать за ресурс, которого они ждали.

    • wait/synch/mutex

      Объект взаимного исключения используется, чтобы разрешить доступ к ресурсу (такому, как раздел выполнимого кода), препятствуя другим потокам получить доступ к ресурсу.

    • wait/synch/rwlock

      Объект блокировки чтения-записи используется, чтобы блокировать определенную переменную для доступа, предотвращая ее использование другими потоками. Совместно используемая блокировка чтения может быть приобретена одновременно многими потоками. Исключительная блокировка записи может быть приобретена только одним потоком за один раз.

    • wait/synch/sxlock

      Совместно используемо-исключительная (SX) блокировка тип объекта блокировки rwlock, который обеспечивает доступ на запись к общему ресурсу, разрешая непоследовательные чтения другим потокам.

23.5. Контроль состояния Performance Schema

Есть несколько переменных состояния, связанных с Performance Schema:

mysql> SHOW STATUS LIKE 'perf%';
+-----------------------------------------------+-------+
| Variable_name                                 | Value |
+-----------------------------------------------+-------+
| Performance_schema_accounts_lost              | 0     |
| Performance_schema_cond_classes_lost          | 0     |
| Performance_schema_cond_instances_lost        | 0     |
| Performance_schema_digest_lost                | 0     |
| Performance_schema_file_classes_lost          | 0     |
| Performance_schema_file_handles_lost          | 0     |
| Performance_schema_file_instances_lost        | 0     |
| Performance_schema_hosts_lost                 | 0     |
| Performance_schema_locker_lost                | 0     |
| Performance_schema_memory_classes_lost        | 0     |
| Performance_schema_metadata_lock_lost         | 0     |
| Performance_schema_mutex_classes_lost         | 0     |
| Performance_schema_mutex_instances_lost       | 0     |
| Performance_schema_nested_statement_lost      | 0     |
| Performance_schema_program_lost               | 0     |
| Performance_schema_rwlock_classes_lost        | 0     |
| Performance_schema_rwlock_instances_lost      | 0     |
| Performance_schema_session_connect_attrs_lost | 0     |
| Performance_schema_socket_classes_lost        | 0     |
| Performance_schema_socket_instances_lost      | 0     |
| Performance_schema_stage_classes_lost         | 0     |
| Performance_schema_statement_classes_lost     | 0     |
| Performance_schema_table_handles_lost         | 0     |
| Performance_schema_table_instances_lost       | 0     |
| Performance_schema_thread_classes_lost        | 0     |
| Performance_schema_thread_instances_lost      | 0     |
| Performance_schema_users_lost                 | 0     |
+-----------------------------------------------+-------+

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

  • Performance_schema_xxx_classes_lost указывает сколько инструментов типа xxx не могли быть загружены.

  • Performance_schema_xxx_instances_lost указывает, сколько экземпляров объекта xxx не могло быть создано.
  • Performance_schema_xxx_handles_lost указывает, сколько экземпляров объекта xxx не могло быть открыто.
  • Performance_schema_locker_lost указывает, сколько событий потеряны или не зарегистрированы.

Например, если mutex инструментован в источнике сервера, но сервер не может выделить память для инструментовки во время выполнения, это увеличивает Performance_schema_mutex_classes_lost. Здесь mutex все еще функционирует как объект синхронизации (то есть, сервер продолжает функционировать обычно), но характеристики для этого не будут собраны. Если инструмент может быть выделен, он может использоваться для того, чтобы инициализировать инструментованные mutex случаи. Для единичного mutex, такого как глобальный mutex, будет только один случай. У других mutex есть случай на соединение или страницу в различных кэшах и буферах данных, таким образом, число случаев изменяется в течение долгого времени. Увеличение максимального количества соединений или максимального размера некоторых буферов увеличит максимальное количество случаев, которые могли бы быть выделены сразу. Если сервер не может создать инструментованный mutex случай, он увеличивает Performance_schema_mutex_instances_lost.

Предположите, что следующие условия выполнены:

  • Сервер был запущен с опцией --performance_schema_max_mutex_classes=200 и таким образом имеет пространство для 200 инструментов mutex.

  • 150 mutex инструментов уже были загружены.
  • Плагин plugin_a содержит 40 инструментов mutex.
  • Плагин plugin_b содержит 20 инструментов mutex.

Сервер выделяет mutex инструменты для плагинов в зависимости от того, в скольких они нуждаются и сколько доступно, как иллюстрировано следующей последовательностью запросов:

INSTALL PLUGIN plugin_a

Сервер теперь имеет 150+40 = 190 mutex.

UNINSTALL PLUGIN plugin_a;

У сервера все еще есть 190 инструментов. Все исторические данные, произведенные сменным кодом, являются все еще доступными, но новые события для инструментов не собраны.

INSTALL PLUGIN plugin_a;

Сервер обнаруживает, что эти 40 инструментов уже определены, таким образом, никакие новые инструменты не создаются, и ранее назначенные внутренние буферы памяти снова использованы. У сервера все еще есть 190 инструментов.

INSTALL PLUGIN plugin_b;

Сервер имеет пространство для 200-190 = 10 инструментов (в этом случае классы mutex) и видит, что плагин содержит 20 новых инструментов. 10 инструментов загружены, а 10 потеряны. Performance_schema_mutex_classes_lost указывает на число потерянных инструментов:

mysql> SHOW STATUS LIKE "perf%mutex_classes_lost";
+---------------------------------------+-------+
| Variable_name                         | Value |
+---------------------------------------+-------+
| Performance_schema_mutex_classes_lost | 10    |
+---------------------------------------+-------+
1 row in set (0.10 sec)

Инструментовка все еще работает и собирает (частичные) данные для plugin_b.

Когда сервер не может создать mutex инструмент, эти результаты происходят:

Этот пример относится ко всем типам инструментов, не только mutex.

Значение Performance_schema_mutex_classes_lost больше 0 может произойти в двух случаях:

  • Чтобы сохранить несколько байтов памяти, Вы запускаете сервер с --performance_schema_max_mutex_classes=N, где N меньше, чем значение по умолчанию. Значение по умолчанию выбрано, чтобы быть достаточным, чтобы загрузить все плагины, обеспеченные в дистрибутиве MySQL, но это может быть уменьшено, если некоторые плагины никогда не загружаются. Например, Вы могли бы хотеть не загружать некоторые из механизмов хранения.

  • Вы загружаете имеющий отношение к третьей стороне плагин, который инструментован для Performance Schema, но не учитываете требования к памяти инструментовки плагина, когда Вы запускаете сервер. Поскольку это прибывает от третьей стороны, инструментальное потребление памяти этого механизма не составляется в значении по умолчанию, выбранном для performance_schema_max_mutex_classes.

    Если у сервера недостаточно ресурсов для инструментов плагина, и Вы явно не выделяете больше, используя --performance_schema_max_mutex_classes=N, загрузка плагина приводит к проблемам.

Если значение, выбранное для performance_schema_max_mutex_classes является слишком маленьким, ни о какой ошибке не сообщают в журнале ошибок и нет никакого отказа во время выполнения. Однако, контент таблиц в performance_schema пропустит события. Переменная состояния Performance_schema_mutex_classes_lost единственный видимый знак указать, что некоторые события были удалены внутренне из-за отказа создать инструменты.

Если инструмент не потерян, он известен Performance Schema и используется, инструментуя случаи. Например, wait/synch/mutex/sql/LOCK_delete имя mutex инструмента в setup_instruments . Этот единственный инструмент используется, создавая mutex в коде (в THD::LOCK_delete), однако, много случаев mutex необходимы, когда сервер работает. В этом случае LOCK_delete mutex для соединения (THD), так что, если у сервера есть 1000 соединений, есть 1000 потоков и 1000 инструментованных случаев LOCK_delete mutex (THD::LOCK_delete).

Если сервер не имеет пространства для инструментованного mutexes всех этих 1000, некоторые mutex создаются с инструментовкой, а некоторые создаются без инструментовки. Если сервер может создать только 800 случаев, 200 случаев потеряны. Сервер продолжает работать, но увеличивает Performance_schema_mutex_instances_lost на 200, чтобы указать, что случаи не могли быть созданы.

Значение Performance_schema_mutex_instances_lost больше 0 может произойти, когда код инициализирует больше mutex во время выполнения, чем было выделено для --performance_schema_max_mutex_instances=N.

-Нижняя строка это если SHOW STATUS LIKE 'perf%' говорит, что ничто не было потеряно (все значения - ноль), Исполнительные данные точны и могут быть использованы. Если что-то было потеряно, данные неполные, и Performance Schema не могла сделать запись всех данных. В этом случае переменная Performance_schema_xxx _lost указывает на проблемную область.

Могло бы быть уместно в некоторых случаях вызвать преднамеренный инструментальный сбой. Например, если Вы не заботитесь о характеристиках ввода/вывода файла, Вы можете запустить сервер со всеми параметрами Performance Schema, связанных с вводом/выводом файла, установленными в 0. Никакая память не будет выделена для связанных с файлом классов, случаев или дескрипторов, и все события файла будут потеряны.

Надо использовать SHOW ENGINE PERFORMANCE_SCHEMA STATUS, чтобы просмотреть внутреннюю работу кода Performance Schema:

mysql> SHOW ENGINE PERFORMANCE_SCHEMA STATUS\G
...
*************************** 3. row ***************************
  Type: performance_schema
  Name: events_waits_history.size
Status: 76
*************************** 4. row ***************************
  Type: performance_schema
  Name: events_waits_history.count
Status: 10000
*************************** 5. row ***************************
  Type: performance_schema
  Name: events_waits_history.memory
Status: 760000
...
*************************** 57. row ***************************
  Type: performance_schema
  Name: performance_schema.memory
Status: 26459600
...

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

23.6. События атома и молекулы Performance Schema

Для табличного случая ввода/вывода обычно есть две строки в events_waits_current . Например, получение строки могло бы привести к строкам как эти:

Row# EVENT_NAME                TIMER_START TIMER_END
---- ----------                ----------- ---------
   1 wait/io/file/myisam/dfile 10001       10002
   2 wait/io/table/sql/handler 10000       NULL

Получение строки вызывает чтение файла. В примере табличный случай ввода/вывода запускался перед случаем ввода/вывода файла, но не закончился (Значение TIMER_END NULL). Случай ввода/вывода файла вложен в пределах табличного случая ввода/вывода.

Это происходит, потому что, в отличие от атомного события (mutex или ввода/вывода файла), табличные события ввода/вывода молекулярные и включают (перекрывают) другие события. В In events_waits_current у табличного случая ввода/вывода обычно есть две строки:

  • Одна строка для ожидания нового табличного ввода/вывода.

  • Одна строка для нового случая ожидания любого вида.

Обычно, но не всегда, случай ожидания отличается от табличного случая ввода/вывода. Поскольку каждый вспомогательный случай завершается, он исчезает из events_waits_current. В этом пункте, пока начинается следующий вспомогательный случай, табличный ввод/вывод также новее ожидания любого вида.

23.7. Обзоры запроса Performance Schema

Сервер MySQL способен к поддержанию информации об обзоре запроса. Процесс переваривания преобразовывает запрос SQL к нормализованной форме и вычисляет значение хеша для результата. Нормализация разрешает запросы, которые подобны, сгруппировать и суммировать, чтобы выставить информацию о типах запросов, которые выполняет сервер и то, как часто они происходят. Этот раздел описывает, как нормализация запросы происходит и как это может быть полезно.

Переваривание происходит на уровне SQL независимо от того, доступна ли Performance Schema, чтобы у других функций сервера, таких как плагины перезаписи запроса был доступ к обзорам запроса.

В Performance Schema запрос вовлекает эти компоненты:

  • Потребитель statement_digest в setup_consumers управляет, поддерживает ли Performance Schema информацию об обзоре.

  • Таблицы запроса событий ( events_statements_current, events_statements_history и events_statements_history_long) имеют столбцы, которые содержат обзоры и соответствующие значения хеша обзора:

    • DIGEST_TEXT текст нормализованного обзора запроса.

    • DIGEST значение хеша MD5 обзора.

    Максимальное пространство, доступное для вычисления обзора, составляет 1024 байта по умолчанию. Это значение может быть изменено при запуске сервера, устанавливая переменную performance_schema_max_digest_length.

  • У таблиц запроса событий также есть столбец SQL_TEXT, который содержит оригинальный запрос SQL. Максимальное пространство, доступное для отображнеия запроса, составляет 1024 байта по умолчанию. Это значение может быть изменено при запуске сервера, устанавливая переменную performance_schema_max_sql_text_length.
  • Таблица events_statements_summary_by_digest предоставляет соединенную информацию об обзоре запроса.

Нормализация преобразовывает текст запроса к более стандартизированному строковому представлению обзора, которое сохраняет структуру общего утверждения, удаляя информацию, не важную для структуры:

  • Сохранены идентификаторы объекта, такие как имена баз данных и таблиц.

  • Буквальные значения преобразованы в маркеры параметра. Нормализованный запрос не сохраняет информацию, такую как имена, пароли, даты и т.д.
  • Комментарии удалены и пробелы скорректированы.

Рассмотрите эти запросы:

SELECT * FROM orders WHERE customer_id=10 AND quantity > 20
SELECT * FROM orders WHERE customer_id = 20 AND quantity > 100

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

SELECT * FROM orders WHERE customer_id = ? AND quantity > ?

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

Теперь рассмотрите эти запросы:

SELECT * FROM customers WHERE customer_id = 1000
SELECT * FROM orders WHERE customer_id = 1000

В этом случае запросы не подобны. Идентификаторы объекта отличаются, таким образом, запросы приводят к различным нормализованным формам:

SELECT * FROM customers WHERE customer_id = ?
SELECT * FROM orders WHERE customer_id = ?

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

SELECT * FROM mytable WHERE cola = 10 AND colb = 20
SELECT * FROM mytable WHERE cola = 10 AND colc = 20

Если сокращение было правильным, после AND у обоих запросов была бы эта нормализованная форма:

SELECT * FROM mytable WHERE cola = ? AND ...

В этом случае различие во втором имени столбца потеряно, и оба запросы считаются подобными.

Для каждого нормализованного запроса Performance Schema вычисляет значение обзора хеша и хранит запрос и его значение хеша MD5 в столбцах DIGEST_TEXT и DIGEST таблиц событий запросов ( events_statements_current, events_statements_history и events_statements_history_long). Кроме того, информация для запросов с теми же самыми значениями SCHEMA_NAME и DIGEST соединена в таблице events_statements_summary_by_digest. Performance Schema использует значения хеша MD5, потому что они быстры, чтобы вычислить и иметь благоприятное статистическое распределение, которое минимизирует столкновения.

Сводная таблица обзора запросов обеспечивает профиль запросов, выполненных сервером. Это показывает, какие виды запросов приложение выполняет и как часто. Разработчик приложений может использовать эту информацию вместе с другой информацией в таблице, чтобы оценить технические характеристики приложения. Например, столбцы таблицы, которые показывают время ожидания, время блокировки или использование индекса, могут выделить типы запросов, которые неэффективны. Это дает понимание разработчика, каким частям приложения необходимо уделять внимание.

events_statements_summary_by_digest имеет фиксированный размер, так что, когда это становится полным, запросы, которые имеют SCHEMA_NAME и DIGEST не соответствующие существующим значениям в таблице, сгруппированы в специальной строке с SCHEMA_NAME и DIGEST NULL. Это разрешает всем запросым быть посчитанными. Однако, если специальная строка составляет существенный процент выполненных запросов, могло бы быть желательно увеличить размер сводной таблицы, устанавливая переменную performance_schema_digests_size к большему значению при запуске сервера. Если не задано значение performance_schema_digests_size, Performance Schema использует значение при запуске.

Переменная performance_schema_max_digest_length определяет максимальное количество байтов, доступных в буфере обзора для вычисления обзора. Однако, длина отображения обзоров может быть больше, чем доступный размер буфера из-за кодирования компонентов запросы, таких как ключевые слова и буквальные значения в буфере обзора. Следовательно, значения, выбранные из столбца DIGEST_TEXT таблиц событий запросов, может казаться, превышает performance_schema_max_digest_length.

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

Чтобы оценить объем памяти, используемый для хранения запроса SQL и вычисления обзора, используйте SHOW ENGINE PERFORMANCE_SCHEMA STATUS или эти инструменты:

mysql> SELECT NAME FROM setup_instruments
                 WHERE NAME LIKE '%.sqltext';
+------------------------------------------------------------------+
| NAME                                                             |
+------------------------------------------------------------------+
| memory/performance_schema/events_statements_history.sqltext      |
| memory/performance_schema/events_statements_current.sqltext      |
| memory/performance_schema/events_statements_history_long.sqltext |
+------------------------------------------------------------------+

mysql> SELECT NAME FROM setup_instruments
                 WHERE NAME LIKE 'memory/performance_schema/%.tokens';
+----------------------------------------------------------------------+
| NAME                                                                 |
+----------------------------------------------------------------------+
| memory/performance_schema/events_statements_history.tokens           |
| memory/performance_schema/events_statements_current.tokens           |
| memory/performance_schema/events_statements_summary_by_digest.tokens |
| memory/performance_schema/events_statements_history_long.tokens      |
+----------------------------------------------------------------------+

23.8. Общие табличные характеристики Performance Schema

Название базы данных performance_schema в нижнем регистре, как названия таблиц в пределах этого. Запросы должны определить имена в нижнем регистре.

Много таблиц в performance_schema только для чтения и не могут быть изменены:

mysql> TRUNCATE TABLE setup_instruments;
ERROR 1683 (HY000): Invalid performance_schema usage.

У некоторых из таблиц установки есть столбцы, которые могут быть изменены, чтобы затронуть работу Performance Schema. Некоторые также разрешают строкам быть вставленными или удаленными. Усечение разрешено для очистки собранных событий, таким образом, TRUNCATE TABLE может использоваться на таблицах, содержащих эти виды информации, такие как таблицы, названные с приставкой events_waits_.

Сводные таблицы могут быть усечены с TRUNCATE TABLE. Вообще, эффект состоит в том, чтобы сбросить сводные столбцы к 0 или NULL, а не удалить строки. Это позволяет очистить собранные значения. Это могло бы быть полезно, например, после того, как Вы произвели изменение конфигурации во время выполнения. Исключения к этому поведению усечения отмечены в отдельных разделах сводной таблицы.

Привилегии что касается других баз данных и таблиц:

  • Чтобы получать данные из таблиц performance_schema, Вы должны иметь привилегию SELECT .

  • Чтобы изменить те столбцы, которые могут быть изменены, Вы должны иметь привилегию UPDATE.
  • Чтобы усечь таблицы, которые могут быть усечены, Вы должны иметь привилегию DROP.

23.9. Описания таблиц Performance Schema

Таблицы в performance_schema могут быть сгруппированы следующим образом:

  • Таблицы установки. Эти таблицы используются, чтобы сконфигурировать и вывести на экран контролирующие характеристики.

  • Таблицы текущих событий. events_waits_current содержит новый случай для каждого потока. Другие подобные таблицы содержат текущие события на разных уровнях иерархии событий: events_stages_current для событий этапа, events_statements_current для событий запросов и events_transactions_current для операционных событий.
  • Таблицы истории. Эти таблицы имеют ту же самую структуру как таблицы текущих событий, но содержат больше строк. Например, для события ожидания events_waits_history содержит новые 10 событий для потока. events_waits_history_long содержит новые 10000 событий. Другие подобные таблицы существуют для этапа, запросов и операционных историй.

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

  • Сводные таблицы. Эти таблицы содержат информацию, соединенную по группам событий, включая те, от которых отказались в таблицах истории.
  • Таблицы случая. Эти таблицы документируют, какие типы объектов инструментованы. Инструментованный объект, когда используется сервером, производит случай. Эти таблицы обеспечивают имена событий и примечания или информацию о статусе.
  • Разные таблицы. Они не попадают ни в одну из других табличных групп.

23.9.1. Индекс таблиц Performance Schema

Следующая таблица приводит каждую таблицу Performance Schema и обеспечивает краткое описание каждой.

Таблица 23.1. Таблицы Performance Schema

ИмяОписание
accounts Статистика соединений на учетную запись клиента
cond_instancesСлучаи синхронизации объекта
data_lock_waitsОтношения ожидания блокировки данных
data_locks Блокировки данных полученные и запрошенные
events_errors_summary_by_account_by_error Ошибки по кодам ошибки на учетную запись
events_errors_summary_by_host_by_error Ошибки по кодам ошибки на хост
events_errors_summary_by_thread_by_error Ошибки по кодам ошибки на хост
events_errors_summary_by_user_by_error Ошибки по кодам ошибки на хост
events_errors_summary_global_by_error Ошибки по кодам ошибки
events_stages_currentТекущие события этапа
events_stages_history Новые события этапа для каждого потока
events_stages_history_long Новые события этапа повсюду
events_stages_summary_by_account_by_event_name События этапа на учетную запись и имя событий
events_stages_summary_by_host_by_event_name События этапа по именам хоста и событий
events_stages_summary_by_thread_by_event_name Этап ожидания на имя события и поток
events_stages_summary_by_user_by_event_name События этапа на имя пользователя и события
events_stages_summary_global_by_event_name Этап ожидания на имя события
events_statements_current Текущие события запроса
events_statements_history Новые события запроса для каждого потока
events_statements_history_long Новые события запроса повсюду
events_statements_summary_by_account_by_event_name События запроса на учетную запись и имя события
events_statements_summary_by_digest События запроса на значение схемы и обзора
events_statements_summary_by_host_by_event_name События запроса на имя хоста и события
events_statements_summary_by_program События запроса на сохраненную программу
events_statements_summary_by_thread_by_event_name События запроса на поток и имя события
events_statements_summary_by_user_by_event_name События запроса на имя пользователя и события
events_statements_summary_global_by_event_name События запроса на имя события
events_transactions_current Текущие операционные события
events_transactions_history Новые операционные события для каждого потока
events_transactions_history_long Новые операционные события повсюду
events_transactions_summary_by_account_by_event_name Операционные события на учетную запись и имя события
events_transactions_summary_by_host_by_event_name Операционные события на имя хоста и события
events_transactions_summary_by_thread_by_event_name Операционные события на поток и имя события
events_transactions_summary_by_user_by_event_name Операционные события на имя пользователя и события
events_transactions_summary_global_by_event_name Операционные события на имя события
events_waits_currentСобытия ожидания потока
events_waits_historyНовые события ожидания каждого потока
events_waits_history_long Новые события ожидания повсюду
events_waits_summary_by_account_by_event_name События ожидания на имя событий и учетную запись
events_waits_summary_by_host_by_event_name События ожидания на имя события и хоста
events_waits_summary_by_instance События ожидания на случай
events_waits_summary_by_thread_by_event_name События ожидания на имя события и поток
events_waits_summary_by_user_by_event_name События ожидания на имя события и пользователя
events_waits_summary_global_by_event_name События ожидания по именам
file_instancesСлучаи файла
file_summary_by_event_nameСобытия файла на имя события
file_summary_by_instanceСобытия файла на случай файла
global_statusГлобальные переменные состояния
global_variablesГлобальные системные переменные
host_cache Информация от внутреннего кэша узла
hosts Статистика соединения на имя хоста клиента
memory_summary_by_account_by_event_name Операции памяти на учетную запись и имя события
memory_summary_by_host_by_event_name Операции памяти на узел и имя события
memory_summary_by_thread_by_event_name Операции памяти на поток и имя события
memory_summary_by_user_by_event_name Операции памяти на пользователя и имя события
memory_summary_global_by_event_name Операции памяти глобально на имя события
metadata_locksМетаданные и запросы блокировки
mutex_instancesСинхронизация экземпляров объекта Mutex
objects_summary_global_by_typeРезюме объекта
performance_timersКакие таймеры событий доступны
prepared_statements_instances Готовые запросы и статистика
replication_applier_configuration Параметры конфигурации для транзакции на ведомом устройстве
replication_applier_status Текущий статус транзакции на ведомом устройстве
replication_applier_status_by_coordinator Статус SQL или координатора потока
replication_applier_status_by_worker Состояние рабочего потока (пусто, если ведомое устройство не является мультипоточным)
replication_connection_configuration Параметры конфигурации для того, чтобы соединиться с ведущим устройством
replication_connection_status Текущий статус соединения с ведущим устройством
rwlock_instancesСинхронизация блокировки объекта
session_account_connect_attrs Атрибуты соединения для текущего сеанса
session_connect_attrsАтрибуты соединения для всех сеансов
session_statusПеременные состояния для текущего сеанса
session_variablesСистемные переменные для текущего сеанса
setup_actorsКак инициализировать контроль для новых потоков переднего плана
setup_consumersПотребители, для которых может быть сохранена информация о событии
setup_instrumentsКлассы инструментованных объектов, для которых могут быть собраны события
setup_objectsКакие объекты должны быть проверены
setup_timersТекущий таймер событий
socket_instancesАктивные соединения
socket_summary_by_event_name Ожидание сокета и ввод/вывод на имя события
socket_summary_by_instance Ожидание сокета и ввод/вывод на случай
status_by_accountПеременные состояния сеанса на учетную запись
status_by_hostПеременные состояния сеанса на имя хоста
status_by_threadПеременные состояния сеанса за сеанс
status_by_userПеременные состояния сеанса на имя пользователя
table_handlesТабличные блокировки и запросы блокировок
table_io_waits_summary_by_index_usage Табличный ввод/вывод, ждущий индекс
table_io_waits_summary_by_table Табличный ввод/вывод на таблицу
table_lock_waits_summary_by_table Табличная блокировка на таблицу
threads Информация о потоках сервера
user_variables_by_thread Определяемые пользователем переменные на поток
users Статистика соединения на имя пользователя клиента
variables_by_threadСистемные переменные сеанса за сеанс
variables_infoКак системные переменные были последний раз установлены

23.9.2. Таблицы установки Performance Schema

Таблицы установки предоставляют информацию о текущей инструментовке и позволяют контролирующей конфигурации быть измененной. Поэтому некоторые столбцы в этих таблицах могут быть изменены, если Вы имеете привилегию UPDATE.

Использование таблиц, а не отдельных переменных для информации об установке обеспечивает высокую степень гибкости в изменении конфигурации Performance Schema. Например, Вы можете использовать единственный запрос со стандартным синтаксисом SQL, чтобы произвести многократные одновременные изменения конфигурации.

Эти таблицы установки доступны:

  • setup_actors : Как инициализировать контроль для новых потоков переднего плана.

  • setup_consumers : Места назначения, в которые информацию о событии можно послать.
  • setup_instruments : Классы инструментованных объектов, для которых могут быть собраны события.
  • setup_objects: Какие объекты должны быть проверены.
  • setup_timers: Текущий таймер событий.

23.9.2.1. Таблица setup_actors

Таблица setup_actors содержит информацию, которая определяет, позволить ли контролировать и журналировать исторические события для новых потоков сервера переднего плана (потоки, связанные с соединениями клиента). У этой таблицы есть максимальный размер 100 строк по умолчанию. Чтобы изменить табличный размер, измените системную переменную performance_schema_setup_actors_size при запуске сервера.

Для каждого нового потока переднего плана Performance Schema соответствует пользователю и узлу в строке таблицы setup_actors. Если строка этой таблицы соответствует, значения ее столбцов ENABLED и HISTORY используются, чтобы установить столбцы INSTRUMENTED и HISTORY, соответственно, в строках таблицы threads для потока. Это позволяет управлять инструментовкой и журналированием исторических событий, которое будет применено выборочно для узла, пользователя или учетной записи (комбинация узла и пользователя). Если нет соответствия, INSTRUMENTED и HISTORY для потока установлены в NO.

Для фоновых потоков нет никакого связанного пользователя. INSTRUMENTED и HISTORY YES по умолчанию и setup_actors не проверяется.

Начальное содержание setup_actors соответствует любой комбинации пользователя и узла, таким образом контроль и сбор исторических событий включены по умолчанию для всех потоков переднего плана:

mysql> SELECT * FROM setup_actors;
+------+------+------+---------+---------+
| HOST | USER | ROLE | ENABLED | HISTORY |
+------+------+------+---------+---------+
| %    | %    | %    | YES     | YES     |
+------+------+------+---------+---------+

Модификации setup_actors вступают в силу только при создании потоков переднего плана после модификации, на существующие потоки изменения не влияют. Чтобы затронуть существующие потоки, измените столбцы INSTRUMENTED и HISTORY строк таблицы threads.

У таблицы setup_actors есть эти столбцы:

  • HOST

    Имя хоста. Это должно быть буквальным именем или '%' означает любой хост.

  • USER

    Имя пользователя. Это должно быть буквальным именем или '%' означает любой пользователь.

  • ROLE

    Не используется.

  • ENABLED

    Включить ли инструментовку для потоков переднего плана, соответствующих строке. Значения YES или NO.

  • HISTORY

    Зарегистрировать ли исторические события для потоков переднего плана, соответствующих строке. Значения YES или NO.

У таблицы setup_actors есть эти индексы:

  • Первичный ключ на (HOST, USER, ROLE).

TRUNCATE TABLE разрешен для setup_actors . Удаляет строки.

23.9.2.2. Таблица setup_consumers

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

mysql> SELECT * FROM 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     |
+----------------------------------+---------+

Модификации setup_consumers действуют немедленно.

У таблицы setup_consumers есть эти столбцы:

  • NAME

    Потребительское имя.

  • ENABLED

    Включен ли потребитель. Значение YES или NO. Этот столбец может быть изменен. Если Вы отключаете потребителя, сервер не тратит время на добавление информацию о событии к этому.

У setup_consumers есть эти индексы:

  • Первичный ключ на (NAME).

TRUNCATE TABLE не разрешен для setup_consumers.

23.9.2.3. Таблица setup_instruments

setup_instruments приводит классы инструментованных объектов, для которых могут быть собраны события:

mysql> SELECT * FROM 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   |
...
| wait/synch/rwlock/sql/LOCK_grant                  | YES     | YES   |
| wait/synch/rwlock/sql/LOGGER::LOCK_logger         | YES     | YES   |
| wait/synch/rwlock/sql/LOCK_sys_init_connect       | YES     | YES   |
| wait/synch/rwlock/sql/LOCK_sys_init_slave         | YES     | YES   |
...
| wait/io/file/sql/binlog                           | YES     | YES   |
| wait/io/file/sql/binlog_index                     | YES     | YES   |
| wait/io/file/sql/casetest                         | YES     | YES   |
| wait/io/file/sql/dbopt                            | YES     | YES   |
...

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

Для некоторых инструментов модификации эффективны только при запуске сервера, изменение их во времени выполнения не имеет никакого эффекта. Это затрагивает прежде всего mutex, условия и rwlocks в сервере, хотя могут быть другие инструменты, для которых это истина. Для большинства изменения вступают в силу сразу.

У setup_instruments есть эти столбцы:

  • NAME

    Инструментальное имя. Инструментальные имена могут иметь много частей и сформировать иерархию, как обсуждено в разделе 23.4. События, произведенные из выполнения инструмента, имеют EVENT_NAME, которое взято от инструментального значения NAME. У событий действительно нет name, но это обеспечивает способ связать события с инструментами.

  • ENABLED

    Включен ли инструмент. Значение YES или NO. Этот столбец может быть изменен. Отключенный инструмент не производит событий.

  • TIMED

    Рассчитан ли инструмент. Этот столбец может быть изменен.

    Для инструментов памяти столбец TIMED в setup_instruments проигнорирован, потому что операции памяти не рассчитаны.

    Если включенный инструмент не рассчитан, инструментальный код включен, но таймер нет. События, произведенные инструментом, имеют NULL для TIMER_START, TIMER_END и TIMER_WAIT. Это в свою очередь заставляет те значения быть проигнорированными, вычисляя сумму, минимум, максимум и средние временные оценки в сводных таблицах.

У setup_instruments есть эти индексы:

  • Первичный ключ на (NAME).

TRUNCATE TABLE не разрешен для setup_instruments.

23.9.2.4. Таблица setup_objects

setup_objects управляет, контролирует ли Performance Schema особые объекты. У этой таблицы есть максимальный размер 100 строк по умолчанию. Чтобы изменить табличный размер, измените переменную performance_schema_setup_objects_size при запуске сервера.

Начальное содержание setup_objects похоже на это:

mysql> SELECT * FROM setup_objects;
+-------------+--------------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME | ENABLED | TIMED |
+-------------+--------------------+-------------+---------+-------+
| EVENT       | mysql              | %           |      NO | NO    |
| EVENT       | performance_schema | %           |      NO | NO    |
| EVENT       | information_schema | %           |      NO | NO    |
| EVENT       | %                  | %           |     YES | YES   |
| FUNCTION    | mysql              | %           |      NO | NO    |
| FUNCTION    | performance_schema | %           |      NO | NO    |
| FUNCTION    | information_schema | %           |      NO | NO    |
| FUNCTION    | %                  | %           |     YES | YES   |
| PROCEDURE   | mysql              | %           |      NO | NO    |
| PROCEDURE   | performance_schema | %           |      NO | NO    |
| PROCEDURE   | information_schema | %           |      NO | NO    |
| PROCEDURE   | %                  | %           |     YES | YES   |
| TABLE       | mysql              | %           |      NO | NO    |
| TABLE       | performance_schema | %           |      NO | NO    |
| TABLE       | information_schema | %           |      NO | NO    |
| TABLE       | %                  | %           |     YES | YES   |
| TRIGGER     | mysql              | %           |      NO | NO    |
| TRIGGER     | performance_schema | %           |      NO | NO    |
| TRIGGER     | information_schema | %           |      NO | NO    |
| TRIGGER     | %                  | %           |     YES | YES   |
+-------------+--------------------+-------------+---------+-------+

Модификации действуют немедленно.

Для типов объекта, перечисленных в setup_objects, Performance Schema использует таблицу для того, как контролировать их. Соответствие лбъектов основано на столбцах OBJECT_SCHEMA и OBJECT_NAME. Объекты, которые не идут ни в какое сравнение, не проверены.

Эффект конфигурации объекта по умолчанию состоит в том, чтобы инструментовать все таблицы кроме в mysql, INFORMATION_SCHEMA и performance_schema. Таблицы в INFORMATION_SCHEMA не инструментована независимо от содержания setup_objects. Строка information_schema.% просто делает это значение явным.

Когда Performance Schema checks проверяет на соответствие setup_objects, это пытается найти более определенные соответствия сначала. Например, с таблицей db1.t1, это ищет совпадение для 'db1' и 't1', потом для 'db1' и '%', потом для '%' и '%'. Порядок, в котором соответствие происходит таков, потому что различные строки setup_objects могут иметь отличающиеся ENABLED и TIMED.

Строки могут быть вставлены или удалены из setup_objects пользователями с привилегиями INSERT или DELETE на таблице. Для существующих строк могут быть изменены только столбцы ENABLED и TIMED пользователями с привилегией UPDATE.

У setup_objects есть эти столбцы:

  • OBJECT_TYPE

    Тип объекта для инструментовки. Значение одно из 'EVENT' (событие Event Scheduler), 'FUNCTION' (сохраненная функция), 'PROCEDURE' (хранимая процедура), 'TABLE' (базовая таблица) или 'TRIGGER' (триггер).

    TABLE фильтрует табличные события ввода/вывода (инструмент wait/io/table/sql/handler) и события блокировки таблицы (wait/lock/table/sql/handler).

  • OBJECT_SCHEMA

    Схема, которая содержит объект. Это должно быть буквальным именем или '%' для любой схемы.

  • OBJECT_NAME

    Название инструментованного объекта. Это должно быть буквальным именем или '%' для любого объекта.

  • ENABLED

    Инструментованы ли события для объекта. Значение YES или NO. Этот столбец может быть изменен.

  • TIMED

    Рассчитаны ли события для объекта. Этот столбец может быть изменен.

У setup_objects есть эти индексы:

  • Индекс на (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME).

TRUNCATE TABLE разрешен для setup_objects . Это удаляет строки.

23.9.2.5. Таблица setup_timers

setup_timers показывает в настоящее время выбираемые таймеры событий:

mysql> SELECT * FROM setup_timers;
+-------------+-------------+
| NAME        | TIMER_NAME  |
+-------------+-------------+
| idle        | MICROSECOND |
| wait        | CYCLE       |
| stage       | NANOSECOND  |
| statement   | NANOSECOND  |
| transaction | NANOSECOND  |
+-------------+-------------+

setup_timers.TIMER_NAME может быть изменено, чтобы выбрать иной таймер. Значение может быть любым из значений в столбце performance_timers.TIMER_NAME.

Изменения в setup_timers действуют немедленно. События, уже происходящие, могут использовать оригинальный таймер в начале и новый таймер в конце. Чтобы избежать непредсказуемых результатов после того, как Вы производите изменения таймера, надо использовать TRUNCATE TABLE для сброса статистики Performance Schema.

У setup_timers есть эти столбцы:

  • NAME

    Тип инструмента, для которого таймер используется.

  • TIMER_NAME

    Таймер, который относится к инструментальному типу. Этот столбец может быть изменен.

У setup_timers есть эти индексы:

  • Первичный ключ на (NAME).

TRUNCATE TABLE не позволен для setup_timers .

23.9.3. Таблицы случая Performance Schema

Таблицы случая документируют, какие типы объектов инструментованы. Они обеспечивают имена событий и примечания или информацию о статусе:

Эти таблицы приводят инструментованные объекты синхронизации, файлы и соединения. Есть три типа объектов синхронизации: cond, mutex и rwlock. Каждая таблица случая имеет столбцы EVENT_NAME или NAME, чтобы указать на инструмент, связанный с каждой строкой. Инструментальные имена могут иметь много частей и сформировать иерархию, как обсуждено в разделе 23.4.

Столбцы mutex_instances.LOCKED_BY_THREAD_ID и rwlock_instances.WRITE_LOCKED_BY_THREAD_ID чрезвычайно важны для исследования исполнительных узких мест или тупиков. Для примеров того, как использовать их с этой целью см. раздел 23.16.

23.9.3.1. Таблица cond_instances

cond_instances приводит все условия, замеченные Performance Schema в то время, как сервер выполняется. Условие это механизм синхронизации, используемый в коде, чтобы сигнализировать, что определенное событие произошло, чтобы поток, ждущий этого условия, мог возобновить работу.

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

У cond_instances есть эти столбцы:

  • NAME

    Инструментальное имя, связанное с условием.

  • OBJECT_INSTANCE_BEGIN

    Адрес в памяти об инструментованном условии.

У cond_instances есть эти индексы:

  • Первичный ключ на (OBJECT_INSTANCE_BEGIN).

  • Индекс на (NAME).

TRUNCATE TABLE не позволен для cond_instances .

23.9.3.2. Таблица file_instances

file_instances приводит все файлы, замеченные Performance Schema, запуская инструментовку ввода/вывода файла. Если файл на диске никогда не открывался, его не будет в file_instances. Когда файл удален с диска, он также удален из file_instances.

У file_instances есть эти столбцы:

  • FILE_NAME

    Имя файла.

  • EVENT_NAME

    Инструментальное имя, связанное с файлом.

  • OPEN_COUNT

    Количество открытых дескрипторов на файле. Если файл был открыт и затем закрыт, он был открыт 1 раз, но OPEN_COUNT будет 0. Чтобы перечислить все файлы, в настоящее время открываемые сервером, надо использовать WHERE OPEN_COUNT > 0.

У file_instances есть эти индексы:

  • Первичный ключ на (FILE_NAME).

  • Индекс на (EVENT_NAME).

TRUNCATE TABLE не позволен для file_instances.

23.9.3.3. Таблица mutex_instances

mutex_instances приводит все mutex, замеченные Performance Schema в то время, как сервер выполняет. mutex это механизм синхронизации, используемый в коде, чтобы провести в жизнь только тот поток, который в установленный срок может иметь доступ к некоторому общему ресурсу. Ресурс, как говорят, при этом является защищенным mutex.

Когда два потока в сервере (например, два пользовательских сеанса, выполняющие запрос одновременно), действительно должны будут получить доступ к тому же самому ресурсу (файлу, буферу или некоторой части данных), эти два потока конкурируют друг против друга так, чтобы первый запрос, который получит блокировку на mutex, заставил другой запрос ждать, пока первый не будет сделан и отпирает mutex.

Это потенциально узкое место, именуемое "критический раздел". Проблема в том, что много потоков вынуждены проходить его строго последовательно и по одному.

У mutex_instances есть эти столбцы:

  • NAME

    Инструментальное имя, связанное с mutex.

  • OBJECT_INSTANCE_BEGIN

    Адрес в памяти об инструментованном mutex.

  • LOCKED_BY_THREAD_ID

    Когда потоку в настоящее время блокировали mutex, LOCKED_BY_THREAD_ID THREAD_ID потока блокировки, иначе это NULL.

У mutex_instances есть эти индексы:

  • Первичный ключ на (OBJECT_INSTANCE_BEGIN).

  • Индекс на (NAME).
  • Индекс на (LOCKED_BY_THREAD_ID).

TRUNCATE TABLE не позволен для mutex_instances .

Для каждого mutex, инструментованного в коде, Performance Schema предоставляет следующую информацию.

  • Таблица setup_instruments приводит название пункта инструментовки, с приставкой wait/synch/mutex/.

  • Когда некоторый код создает mutex, строка добавлена к таблице mutex_instances. Столбец OBJECT_INSTANCE_BEGIN свойство, которое уникально идентифицирует mutex.
  • Когда поток пытается заблокировать mutex, events_waits_current показывает строку для этого потока, указывая, что он ждет mutex (в столбце EVENT_NAME) и указание, какой mutex ждут (в столбце OBJECT_INSTANCE_BEGIN).
  • Когда поток преуспевает в том, чтобы блокировать mutex:

  • Когда поток отпирает mutex, mutex_instances показывает, что у mutex теперь нет никакого владельца (THREAD_ID NULL).

  • Когда объект mutex разрушен, соответствующая строка удалена из mutex_instances.

Выполняя запросы на обеих из следующих таблиц, контролирующее приложение или DBA могут обнаружить узкие места или тупики между потоками, которые вовлекают mutex:

  • events_waits_current, чтобы видеть, какой mutex ждет поток.

  • mutex_instances , чтобы видеть, какому другому потоку в настоящее время принадлежит mutex.

23.9.3.4. Таблица rwlock_instances

Таблица rwlock_instances приводит все rwlock (read write lock) случаи, замеченные Performance Schema в то время, как сервер выполняется. rwlock механизм синхронизации, используемый в коде, чтобы провести в жизнь то, который поток в установленный срок может иметь доступ к некоторому общему ресурсу по определенным правилам. Ресурс, как говорят, является защищенным rwlock. Доступ совместно использован (у многих потоков может быть блокировка чтения в то же самое время), исключительный (только у одного потока может быть блокировка записи в установленный срок) или совместно используемо-исключительный (у потока может быть блокировка записи, разрешая непоследовательные чтения другими потоками). Совместно используемый эксклюзивный доступ иначе известен как sxlock и был введен в MySQL 5.7, чтобы оптимизировать параллелизм и улучшить масштабируемость для чтения-записи.

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

У rwlock_instances есть эти столбцы:

  • NAME

    Инструментальное имя, связанное с блокировкой.

  • OBJECT_INSTANCE_BEGIN

    Адрес в памяти об инструментованной блокировке.

  • WRITE_LOCKED_BY_THREAD_ID

    Когда поток в настоящее время имеет rwlock заблокированную в исключительном (записи) режиме, WRITE_LOCKED_BY_THREAD_ID THREAD_ID потока блокировки, иначе NULL.

  • READ_LOCKED_BY_COUNT

    Когда поток в настоящее время имеет rwlock заблокированную в совместно используемом (чтение) режиме, READ_LOCKED_BY_COUNT увеличен на 1. Это только счетчик, таким образом, это не может использоваться непосредственно, чтобы найти, какой поток держит блокировку чтения, но это может использоваться, чтобы видеть, есть ли чтение на rwlock, и сколько читателей в настоящее время активно.

У rwlock_instances есть эти индексы:

  • Первичный ключ на (OBJECT_INSTANCE_BEGIN).

  • Индекс на (NAME).
  • Индекс на (WRITE_LOCKED_BY_THREAD_ID).

TRUNCATE TABLE не позволен для rwlock_instances.

Выполняя запросы на обеих из следующих таблиц, контролирующее приложение или DBA могут обнаружить некоторые узкие места или тупики между потоками, которые вовлекают блокировки:

  • events_waits_current, чтобы видеть, что поток ждет rwlock.

  • rwlock_instances , чтобы видеть который другой поток в настоящее время имеет rwlock.

Есть ограничение: rwlock_instances может использоваться только, чтобы идентифицировать поток, держащий блокировку записи, но не потоки, держащие блокировку чтения.

23.9.3.5. Таблица socket_instances

socket_instances обеспечивает снимок в реальном времени активных соединений с сервером MySQL. Таблица содержит одну строку на TCP/IP или соединение файла сокета Unix. Информация, доступная в этой таблице, обеспечивает снимок в реальном времени активных соединений с сервером. Дополнительная информация доступна в сводных таблицах сокета, включая такую сетевую деятельность, как операции сокета и число байтов, переданных и полученных, см. раздел 23.9.15.8).

mysql> SELECT * FROM socket_instances\G
*************************** 1. row ***************************
 EVENT_NAME: wait/io/socket/sql/server_unix_socket
OBJECT_INSTANCE_BEGIN: 4316619408
THREAD_ID: 1
SOCKET_ID: 16
 IP:
 PORT: 0
STATE: ACTIVE
*************************** 2. row ***************************
 EVENT_NAME: wait/io/socket/sql/client_connection
OBJECT_INSTANCE_BEGIN: 4316644608
THREAD_ID: 21
SOCKET_ID: 39
 IP: 127.0.0.1
 PORT: 55233
STATE: ACTIVE
*************************** 3. row ***************************
 EVENT_NAME: wait/io/socket/sql/server_tcpip_socket
OBJECT_INSTANCE_BEGIN: 4316699040
THREAD_ID: 1
SOCKET_ID: 14
 IP: 0.0.0.0
 PORT: 50603
STATE: ACTIVE

У инструментов сокета есть названия формы wait/io/socket/sql/socket_type и используются как это:

  1. У сервера есть сокет для каждого сетевого протокола, который он поддерживает. У инструментов, связанных с сокетами для TCP/IP или соединений файла сокета Unix, есть socket_type server_tcpip_socket или server_unix_socket, соответственно.

  2. Когда сокет обнаруживает соединение, сервер передает соединение с новым сокетом, которым управляет отдельный поток. У инструмента для нового потока соединения есть socket_type client_connection.
  3. Когда соединение заканчивается, строка в socket_instances , соответствующая ему удалена.

У socket_instances есть эти столбцы:

  • EVENT_NAME

    Название инструмента wait/io/socket/*, который произвел случай. Это значение NAME из setup_instruments . Инструментальные имена могут иметь многое частей и сформировать иерархию, как обсуждено в разделе 23.4.

  • OBJECT_INSTANCE_BEGIN

    Этот столбец уникально идентифицирует сокет. Значение адрес объекта в памяти.

  • THREAD_ID

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

  • SOCKET_ID

    Внутренний дескриптор, назначенный на сокет.

  • IP

    IP-адрес клиента. Значение может быть адресом IPv4, IPv6 или пустым, чтобы указать на соединение файла сокета Unix.

  • PORT

    Номер порта TCP/IP в диапазоне от 0 до 65535.

  • STATE

    Состояние сокета IDLE или ACTIVE. Ожидания для активных сокетов прослежены, используя соответствующий инструмент сокета. Ожидания для неактивных сокетов прослежены, используя инструмент idle.

    Сокет неактивен, если ждет запроса от клиента. Когда сокет становится неактивным, строка событий в socket_instances отслеживает переход сокета от состояния ACTIVE в IDLE. Значение EVENT_NAME остается wait/io/socket/*, но синхронизация для инструмента приостановлена. Вместо этого случай произведен в таблице events_waits_current с EVENT_NAME idle.

    Когда следующий запрос получен, idle заканчивается, сокета переходит от IDLE к ACTIVE, а синхронизация инструмента сокета восстанавливается.

У socket_instances есть эти индексы:

  • Первичный ключ на (OBJECT_INSTANCE_BEGIN).

  • Индекс на (THREAD_ID).
  • Индекс на (SOCKET_ID).
  • Индекс на (IP, PORT).

TRUNCATE TABLE не позволен для socket_instances.

Значение комбинации столбца IP:PORT идентифицирует соединение. Это значение комбинации используется в столбце the OBJECT_NAME таблицы events_waits_xxx , чтобы идентифицировать соединение, из которого прибывают события сокета:

  • Для сокета домена Unix (server_unix_socket) порт 0, IP ''.

  • Для соединений клиента через домен Unix (client_connection) порт 0, IP ''.
  • Для сокета сервера TCP/IP (server_tcpip_socket), порт всегда основной порт (например, 3306), IP всегда 0.0.0.0.
  • Для соединений клиента через TCP/IP (client_connection) порт тот, что сервер назначает, но никогда 0. IP указывает IP удаленного узла (127.0.0.1 или ::1 для localhost).

23.9.4. Таблицы ожидания событий Performance Schema

Эти таблицы хранят ожидание события:

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

Конфигурация событий ожидания

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

setup_instruments содержит инструменты с именами, которые начинаются с wait. Например:

mysql> SELECT * FROM setup_instruments
                   WHERE NAME LIKE 'wait/io/file/innodb%';
+--------------------------------------+---------+-------+
| NAME                                 | ENABLED | TIMED |
+--------------------------------------+---------+-------+
| wait/io/file/innodb/innodb_data_file | YES     | YES   |
| wait/io/file/innodb/innodb_log_file  | YES     | YES   |
| wait/io/file/innodb/innodb_temp_file | YES     | YES   |
+--------------------------------------+---------+-------+

mysql> SELECT * FROM setup_instruments
                   WHERE NAME LIKE 'wait/io/socket/%';
+----------------------------------------+---------+-------+
| NAME                                   | ENABLED | TIMED |
+----------------------------------------+---------+-------+
| wait/io/socket/sql/server_tcpip_socket | NO      | NO    |
| wait/io/socket/sql/server_unix_socket  | NO      | NO    |
| wait/io/socket/sql/client_connection   | NO      | NO    |
+----------------------------------------+---------+-------+

Чтобы изменить набор событий, изменяют столбцы ENABLED и TIMING соответствующих инструментов. Например:

mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'
                 WHERE NAME LIKE 'wait/io/socket/sql/%';

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

mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%waits%';
+---------------------------+---------+
| NAME                      | ENABLED |
+---------------------------+---------+
| events_waits_current      | NO      |
| events_waits_history      | NO      |
| events_waits_history_long | NO      |
+---------------------------+---------+

Чтобы включить всех потребителей:

mysql> UPDATE setup_consumers SET ENABLED = 'YES'
                 WHERE NAME LIKE '%waits%';

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

mysql> SELECT * FROM setup_timers WHERE NAME = 'wait';
+------+------------+
| NAME | TIMER_NAME |
+------+------------+
| wait | CYCLE      |
+------+------------+

Чтобы изменить модуль синхронизации, измените значение TIMER_NAME:

mysql> UPDATE setup_timers SET TIMER_NAME = 'NANOSECOND'
                 WHERE NAME = 'wait';

23.9.4.1. Таблица events_waits_current

events_waits_current содержит текущие события ожидания, одна строка на поток, показывая текущий статус недавно проверенных событий ожидания потока.

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

У events_waits_current есть эти столбцы:

  • THREAD_ID, EVENT_ID

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

  • END_EVENT_ID

    Этот столбец установлен в NULL, когда случай запускается, и обновленный к числу текущих событий потока, когда случай заканчивается.

  • EVENT_NAME

    Название инструмента, который произвел случай. Это NAME из setup_instruments . Инструментальные имена могут иметь много частей и сформировать иерархию, как обсуждено в разделе 23.4.

  • SOURCE

    Название исходного файла, содержащего инструментованный код, который произвел случай и номер строки в файле, в которой происходит инструментовка. Это позволяет Вам проверить источник, чтобы определить точно, какой код вовлечен. Например, если блокировка или mutex блокируются, Вы можете проверить контекст, в котором это происходит.

  • TIMER_START, TIMER_END, TIMER_WAIT

    Информация о синхронизации для случая. Модуль для этих значений пикосекунда. TIMER_START и TIMER_END указывают, когда синхронизация событий запустилась и закончилась. TIMER_WAIT продолжительность события.

    Если случай не закончился, TIMER_END текущее значение таймера и TIMER_WAIT уже прошедшее время (TIMER_END - TIMER_START).

    Если случай произведен из инструмента, который имеет TIMED = NO, информация синхронизации не собрана, TIMER_START, TIMER_END и TIMER_WAIT NULL.

  • SPINS

    Для mutex число спинов. Если значение NULL, код не использует спины или они не инструментованы.

  • OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE, OBJECT_INSTANCE_BEGIN

    Эти столбцы идентифицируют объект как действует. Что это означает, зависит от типа объекта.

    Для объекта синхронизации (cond, mutex, rwlock):

    • OBJECT_SCHEMA, OBJECT_NAME и OBJECT_TYPE NULL.

    • OBJECT_INSTANCE_BEGIN адрес объекта синхронизации в памяти.

    Для объекта ввода/вывода файла:

    • OBJECT_SCHEMA NULL.

    • OBJECT_NAME имя файла.
    • OBJECT_TYPE FILE.
    • OBJECT_INSTANCE_BEGIN адрес в памяти.

    Для объекта сокета:

    • OBJECT_NAME IP:PORT для сокета.

    • OBJECT_INSTANCE_BEGIN адрес в памяти.

    Для табличного объекта ввода/вывода:

    • OBJECT_SCHEMA название схемы, которая содержит таблицу.

    • OBJECT_NAME имя таблицы.
    • OBJECT_TYPE TABLE для постоянной базовой таблицы или TEMPORARY TABLE для временной таблицы.
    • OBJECT_INSTANCE_BEGIN адрес в памяти.

    У самого значения OBJECT_INSTANCE_BEGIN нет никакого значения, за исключением того, что различные значения указывают на различные объекты. OBJECT_INSTANCE_BEGIN может использоваться для того, чтобы отладить. Например, это может использоваться с GROUP BY OBJECT_INSTANCE_BEGIN, чтобы видеть, что загрузка 1000 mutex (которые защищают, скажем, 1000 страниц или блоков данных) распространена равномерно или поражает только несколько узких мест. Это может помочь Вам коррелировать с другими источниками информации, если Вы видите тот же самый адрес объекта в файле системного журнала или другом инструменте отладки.

  • INDEX_NAME

    Имя индекса. PRIMARY указывает на первичный индекс таблицы. NULL значит, что использовались средства, которые не индексируют.

  • NESTING_EVENT_ID

    EVENT_ID значение случая, в пределах которого вложен этот случай.

  • NESTING_EVENT_TYPE

    Тип вложения событий. Значение TRANSACTION, STATEMENT, STAGE или WAIT.

  • OPERATION

    Тип работы lock, read или write.

  • NUMBER_OF_BYTES

    Число байтов, прочитанных или записанных. Для табличного ожидания ввода/вывода (события для инструмента wait/io/table/sql/handler ) NUMBER_OF_BYTES указывает на число строк. Если значение больше 1, это случай пакетной работы ввода/вывода. Следующее обсуждение описывает различие между сообщением о единственной строке и сообщением, что это отражает пакетный ввод/вывод.

    MySQL выполняет соединения, используя выполнение вложенного цикла. Задание инструментовки Performance Schema должно предоставить количество строк и накопленное время выполнения на таблицу в соединении. Примите запрос соединения следующей формы, которая выполнена, используя табличный порядок соединения t1, t2, t3:

    SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...
    

    Таблица fanout увеличена или уменьшена в числе строк от добавления таблицы во время обработки соединения. Если разветвление для таблицы t3 больше 1, большинство операций получения строки для этой таблицы. Предположите, что соединение получает 10 строк из t1, 20 из t2 на строку из t1 и 30 строк из t3 на строку из t2. С сообщением единственной строки общее количество инструментованных операций:

    10 + (10 * 20) + (10 * 20 * 30) = 6210
    

    Значительное сокращение числа инструментованных операций достижимо, соединяя их за просмотр (то есть, за уникальную комбинацию строк из t1 и t2). С пакетным сообщением ввода/вывода Performance Schema производит случай для каждого просмотра самой внутренней таблицы t3, а не для каждой строки, и число инструментованных операций строки уменьшается до:

    10 + (10 * 20) + (10 * 20) = 410
    

    Это сокращение на 93% иллюстрирует, как сообщающая о пакете стратегия значительно уменьшает издержки Performance Schema для табличного ввода/вывода, сокращая количество сообщений о требованиях. Расплата: меньшая точность для синхронизации событий. А не время для отдельной работы строки как в сообщении на строку, синхронизация для пакетного ввода/вывода включает время, проведенное для таких операций, как буферизация соединения, объединение и возвращение строк клиенту.

    Для пакетного ввода/вывода эти условия должны быть истиной:

    • Выполнение запроса получает доступ к самой внутренней таблице блока запроса (для однотабличного запроса эта таблица считается самой внутренней).

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

  • FLAGS

    Сохранено для будущего использования.

У events_waits_current есть эти индексы:

  • Первичный ключ на (THREAD_ID, EVENT_ID).

TRUNCATE TABLE позволен для events_waits_current. Это удаляет строки.

23.9.4.2. Таблица events_waits_history

events_waits_history содержит новые N событий ожидания на поток. Значение N автоизмерено при запуске сервера. Чтобы установить табличный размер явно, установите переменную performance_schema_events_waits_history_size при запуске сервера. События не добавлены к таблице, пока они не закончены. Когда новые события добавлены, от более старых событий отказываются, если таблица полна.

У events_waits_history есть та же самая структура, как у events_waits_current , включая индексацию. См. раздел 23.9.4.1.

TRUNCATE TABLE разрешен для events_waits_history. Это удаляет строки.

23.9.4.3. Таблица events_waits_history_long

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

events_waits_history_long имеет структуру, аналогичную events_waits_current , но не имеет индексов. См. раздел 23.9.4.1.

TRUNCATE TABLE позволен на events_waits_history_long. Это удаляет строки.

23.9.5. Таблицы событий этапа Performance Schema

Инструменты этапа Performance Schema, которые являются шагами во время процесса выполнения запроса, такими как парсинг запроса, открытие таблицы или выполнение filesort. Этапы соответствуют статусам, отображенным SHOW PROCESSLIST или видимым в таблице INFORMATION_SCHEMA.PROCESSLIST. Этапы начинаются и заканчиваются, когда статус оценивает изменение.

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

Конфигурация событий этапа

Чтобы включить сбор событий этапа, включите соответствующие инструменты и потребителей.

setup_instruments содержит инструменты с именами, которые начинаются с stage. Кроме тех инструментов, которые предоставляют информацию о продвижении запроса, эти инструменты отключены по умолчанию. Например:

mysql> SELECT * FROM setup_instruments WHERE NAME RLIKE 'stage/sql/[a-c]';
+----------------------------------------------------+---------+-------+
| NAME                                               | ENABLED | TIMED |
+----------------------------------------------------+---------+-------+
| stage/sql/After create                             | NO      | NO    |
| stage/sql/allocating local table                   | NO      | NO    |
| stage/sql/altering table                           | NO      | NO    |
| stage/sql/committing alter table to storage engine | NO      | NO    |
| stage/sql/Changing master                          | NO      | NO    |
| stage/sql/Checking master version                  | NO      | NO    |
| stage/sql/checking permissions                     | NO      | NO    |
| stage/sql/checking privileges on cached query      | NO      | NO    |
| stage/sql/checking query cache for query           | NO      | NO    |
| stage/sql/cleaning up                              | NO      | NO    |
| stage/sql/closing tables                           | NO      | NO    |
| stage/sql/Connecting to master                     | NO      | NO    |
| stage/sql/converting HEAP to MyISAM                | NO      | NO    |
| stage/sql/Copying to group table                   | NO      | NO    |
| stage/sql/Copying to tmp table                     | NO      | NO    |
| stage/sql/copy to tmp table                        | NO      | NO    |
| stage/sql/Creating sort index                      | NO      | NO    |
| stage/sql/creating table                           | NO      | NO    |
| stage/sql/Creating tmp table                       | NO      | NO    |
+----------------------------------------------------+---------+-------+

Инструменты событий этапа, которые предоставляют информацию о продвижении запроса, включены и рассчитаны по умолчанию:

mysql> SELECT * FROM setup_instruments WHERE ENABLED='YES' AND
                   NAME LIKE "stage/%";
+------------------------------------------------------+---------+-------+
| NAME                                                 | ENABLED | TIMED |
+------------------------------------------------------+---------+-------+
| stage/sql/copy to tmp table                          | YES     | YES   |
| stage/innodb/alter table (end)                       | YES     | YES   |
| stage/innodb/alter table (flush)                     | YES     | YES   |
| stage/innodb/alter table (insert)                    | YES     | YES   |
| stage/innodb/alter table (log apply index)           | YES     | YES   |
| stage/innodb/alter table (log apply table)           | YES     | YES   |
| stage/innodb/alter table (merge sort)                | YES     | YES   |
| stage/innodb/alter table (read PK and internal sort) | YES     | YES   |
| stage/innodb/buffer pool load                        | YES     | YES   |
+------------------------------------------------------+---------+-------+

Чтобы изменить набор событий этапа, измените столбцы ENABLED и TIMING соответствующих инструментов. Например:

mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'
                 WHERE NAME = 'stage/sql/altering table';

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

mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%stages%';
+----------------------------+---------+
| NAME                       | ENABLED |
+----------------------------+---------+
| events_stages_current      | NO      |
| events_stages_history      | NO      |
| events_stages_history_long | NO      |
+----------------------------+---------+

Чтобы включить всех потребителей этапа:

mysql> UPDATE setup_consumers SET ENABLED = 'YES'
                 WHERE NAME LIKE '%stages%';

setup_timers содержит строку NAME со значением stage, которая указывает на модуль для синхронизации этапа событий. Модуль по умолчанию NANOSECOND.

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

Чтобы изменить модуль синхронизации, измените значение TIMER_NAME:

mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'
                 WHERE NAME = 'stage';

Информация о продвижении этапа событий

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

  • WORK_COMPLETED: Число единиц работы, которые завершились для этапа.

  • WORK_ESTIMATED: Число единиц работы, которые ожидаются для этапа.

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

  • Единица работы является метрикой целого числа, которая увеличивается в течение долгого времени во время выполнения, такое как число байтов, строк, файлов или обработанных таблиц. Определение единицы работы для особого инструмента оставляют коду инструментовки, обеспечивающему данные.

  • Значение WORK_COMPLETED может увеличиться на один или много модулей за один раз, в зависимости от инструментованного кода.
  • Значение WORK_ESTIMATED может измениться во время этапа, в зависимости от инструментованного кода.

Инструментовка для индикатора хода выполнения этапа событий может осуществить любое из следующих поведений:

  • Никакого прогресса нет.

    Это самый типичный случай, где никакие данные о продвижении не обеспечены. Столбцы WORK_COMPLETED и WORK_ESTIMATED оба NULL.

  • Неограниченная инструментовка продвижения.

    Только столбец WORK_COMPLETED является значащим. Никакие данные не предусмотрены для WORK_ESTIMATED, который выводит на экран 0.

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

  • Ограниченная инструментовка продвижения.

    Столбцы WORK_COMPLETED и WORK_ESTIMATED являются оба значащими.

    Этот тип индикатора хода выполнения является подходящим для работы с определенным критерием завершения, таким как инструмент табличной копии, описанный позже. Запрашивая таблицу events_stages_current для проверенного сеанса, контролирующее приложение может сообщить, сколько работы до сих пор выполнялось, и может сообщить о полном проценте завершения для этапа, вычисляя коэффициент WORK_COMPLETED/WORK_ESTIMATED.

Инструмент stage/sql/copy to tmp table иллюстрирует, как работают индикаторы хода выполнения. Во время выполнения ALTER TABLE этап stage/sql/copy to tmp table используется, и этот этап может выполняться потенциально в течение долгого времени, в зависимости от размера данных.

У задачи табличной копии есть определенное завершение (все строки скопированы) и stage/sql/copy to tmp table инструментован к предоставленной ограниченной информации о продвижении: используемая единица работы является числом скопированных строк, WORK_COMPLETED и WORK_ESTIMATED являются значащими, а их отношение указывает на процент выполнения задачи.

Чтобы включить инструмент и соответствующих потребителей, выполните эти запросы:

mysql> UPDATE setup_instruments SET ENABLED='YES'
                 WHERE NAME='stage/sql/copy to tmp table';
mysql> UPDATE setup_consumers SET ENABLED='YES'
                 WHERE NAME LIKE 'events_stages_%';

Чтобы видеть ход продолжающегося запроса ALTER TABLE, выберите из таблицы events_stages_current.

23.9.5.1. Таблица events_stages_current

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

Из таблиц, которые содержат строки этапа событий, events_stages_current является самой фундаментальной. Другие таблицы, которые содержат строки этапа событий, логически получены из текущих событий. Например, events_stages_history и events_stages_history_long собирают новые события этапа до постоянного числа строк.

У events_stages_current есть эти столбцы:

  • THREAD_ID, EVENT_ID

    Поток, связанный со случаем и числом событий потока, когда случай запускается. THREAD_ID и EVENT_ID, взятые вместе, уникально идентифицируют строку. Ни у каких двух строк нет той же самой пары значений.

  • END_EVENT_ID

    Этот столбец установлен в NULL, когда случай запускается, и обновлен к числу событий потока, когда случай заканчивается.

  • EVENT_NAME

    Название инструмента, который произвел случай. Это значение NAME из setup_instruments. Инструментальные имена могут иметь много частей и сформировать иерархию, как обсуждено в разделе 23.4.

  • SOURCE

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

  • TIMER_START, TIMER_END, TIMER_WAIT

    Информация о синхронизации для случая. Модуль для этих значений пикосекунды. TIMER_START и TIMER_END указывают, когда синхронизация событий запустилась и закончилась. TIMER_WAIT продолжительность событий.

    Если случай не закончился, TIMER_END текущее значение таймера и TIMER_WAIT время, законченное до сих пор (TIMER_END - TIMER_START).

    Если случай произведен из инструмента, который имеет TIMED = NO, информация синхронизации не собрана, TIMER_START, TIMER_END и TIMER_WAIT все NULL.

  • WORK_COMPLETED, WORK_ESTIMATED

    Эти столбцы предоставляют информацию о продвижении этапа для инструментов, которые были осуществлены, чтобы произвести такую информацию. WORK_COMPLETED указывает, сколько единиц работы было завершено для этапа, а WORK_ESTIMATED указывает, сколько единиц работы ожидается для этапа.

  • NESTING_EVENT_ID

    Значение EVENT_ID случая, в пределах которого вложен этот случай. Событие вложения для случая этапа обычно событие запроса.

  • NESTING_EVENT_TYPE

    Тип вложения событий. Значение TRANSACTION, STATEMENT, STAGE или WAIT.

У events_stages_current есть эти индексы:

  • Первичный ключ на (THREAD_ID, EVENT_ID).

TRUNCATE TABLE позволен на events_stages_current. Это удаляет строки.

23.9.5.2. Таблица events_stages_history Table

events_stages_history содержит N новых событий этапа на поток. Значение N определено при запуске сервера. Чтобы установить табличный размер явно, установите при запуске сервера переменную performance_schema_events_stages_history_size. События этапа не добавлены к таблице, пока они не закончены. Когда новые события добавлены, от более старых событий отказываются, если таблица полна.

У events_stages_history есть та же самая структура, как у events_stages_current , включая индексы. См. раздел 23.9.5.1.

TRUNCATE TABLE позволен на events_stages_history. Это удаляет строки.

23.9.5.3. Таблица events_stages_history_long

events_stages_history_long содержит N новых событий этапа. N определено при запуске сервера. Чтобы установить табличный размер явно, установите при запуске сервера переменную performance_schema_events_stages_history_long_size. События этапа не добавлены к таблице, пока они не закончились. Когда новые события добавлены, от более старых событий отказываются, если таблица полна. Когда поток заканчивается, его строки удалены из таблицы.

У events_stages_history_long есть та же самая структура, как у events_stages_current , но нет индексов. См. раздел 23.9.5.1.

TRUNCATE TABLE позволен на events_stages_history_long. Это удаляет строки.

23.9.6. Таблицы событий запросов Performance Schema

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

Конфигурация событий запросов

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

Таблица setup_instruments содержит инструменты с именами, которые начинаются с statement. Эти инструменты включены по умолчанию:

mysql> SELECT * FROM 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   |
+--------------------------------+---------+-------+

Чтобы изменить набор событий запросов, измените столбцы ENABLED и TIMING соответствующих инструментов. Например:

mysql> UPDATE setup_instruments SET ENABLED = 'NO'
                 WHERE NAME LIKE 'statement/com/%';

setup_consumers содержит потребительские значения с именами, соответствующими текущим и недавним именам событий запросов и потребителю обзора запросов. Эти потребители могут использоваться, чтобы фильтровать набор событий. events_statements_current, events_statements_history и statements_digest включены по умолчанию:

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

Чтобы включить всех потребителей, сделайте это:

mysql> UPDATE setup_consumers SET ENABLED = 'YES'
                 WHERE NAME LIKE '%statements%';

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

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

Чтобы изменить модуль синхронизации, измените значение TIMER_NAME:

mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'
                 WHERE NAME = 'statement';

Контроль запросов

Контроль запросов начинается с момента, когда сервер видит, что на потоке требуется активность, до момента, когда вся деятельность прекратилась. Как правило, это означает по времени от момента, когда сервер получает первый пакет от клиента, до времени, когда сервер закончил посылать ответ. Запросы в пределах сохраненных программ проверены как другие запросы.

Когда Performance Schema инструментует запрос (команду сервера или запрос SQL), это использует инструментальные имена, которые проистекают из более общего (или абстрактного) к более определенному, пока это не достигает заключительного инструментального имени.

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

  • Команды сервера соответствуют кодам COM_xxx, определенным в заголовочном файле 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 и случай запроса содержит информацию, чтобы указать на природу ошибки.

Запрос может быть получен из любого из этих источников:

  • Как команда или запрос от клиента, который посылает запрос как пакет.

  • Как строка запроса, считанная из протокола на ведомом устройстве.
  • Как событие от Event Scheduler.

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

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

  1. Когда сервер обнаруживает новый пакет на уровне сокета, новое запрос запущен с абстрактного инструментального названия statement/abstract/new_packet.

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

Для чтения запроса как запроса от протокола ведомого устройства:

  1. Запросы в журнале сохранены как текст и считаны как есть. Нет никакого сетевого протокола, таким образом, инструмент statement/abstract/new_packet не используется. Вместо этого начальный инструмент statement/abstract/relay_log.

  2. Когда запрос разобран, точный тип запроса известен. Если запрос, например, INSERT, Performance Schema совершенствует инструментальное имя от statement/abstract/Query до statement/sql/insert, что является заключительным именем.

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

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

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

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

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

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

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

23.9.6.1. Таблица The events_statements_current

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

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

У events_statements_current есть эти столбцы:

  • THREAD_ID, EVENT_ID.

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

  • END_EVENT_ID

    Этот столбец установлен в NULL, когда случай запускается и обновлен к числу событий потока, когда случай заканчивается.

  • EVENT_NAME

    Название инструмента, у которого был собран случай. Это NAME из таблицы setup_instruments. Инструментальные имена могут иметь много частей и сформировать иерархию, как обсуждено в разделе 23.4.

    Для запросов SQL EVENT_NAME первоначально statement/com/Query пока запрос не разобран, затем изменяется на более соответствующее значение, как описано в разделе 23.9.6.

  • SOURCE

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

  • TIMER_START, TIMER_END, TIMER_WAIT

    Информация о синхронизации для случая. Модуль для этих значений пикосекунды TIMER_START и TIMER_END указывают, когда синхронизация событий запустилась и закончилась. TIMER_WAIT продолжительность событий.

    Если случай не закончился, TIMER_END текущее значение таймера и TIMER_WAIT время, законченное до сих пор (TIMER_END - TIMER_START).

    Если случай произведен из инструмента, который имеет TIMED = NO, информация синхронизации не собрана, а TIMER_START, TIMER_END и TIMER_WAIT NULL.

  • LOCK_TIME

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

  • SQL_TEXT

    Текст запроса SQL. Для команды, не связанной с запросом SQL, значение NULL.

    Максимальное количество байтов, чтобы вывести на экран может быть изменено, изменяя при запуске сервера переменную performance_schema_max_sql_text_length.

  • DIGEST

    Обзор запроса MD5 как строка из 32 шестнадцатеричных символов или NULL, если потребитель statement_digest no.

  • DIGEST_TEXT

    Нормализованный текст обзора запроса или NULL, если потребитель statement_digest no.

    Перменная performance_schema_max_digest_length определяет максимальное количество байтов, доступных для вычислительных обзоров запроса. Однако, длина отображения обзоров запроса может быть более длительной, чем доступный размер буфера из-за кодирования компонентов запроса, таких как ключевые слова и буквальные значения в буфере обзора. Следовательно, значения, выбранные из столбца DIGEST_TEXT таблиц событий запроса, может казаться, превышает performance_schema_max_digest_length.

  • CURRENT_SCHEMA

    База данных значения по умолчанию для запроса, NULL, если нет.

  • OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE

    Для вложенных запросов (сохраненные программы), эти столбцы содержат информацию о родительском запросе. Иначе NULL.

  • OBJECT_INSTANCE_BEGIN

    Этот столбец идентифицирует запрос. Значение адрес объекта в памяти.

  • MYSQL_ERRNO

    Код ошибки из области диагностики.

  • RETURNED_SQLSTATE

    Значение SQLSTATE из области диагностики.

  • MESSAGE_TEXT

    Сообщение об ошибке запроса из области диагностики.

  • ERRORS

    Произошла ли ошибка для запроса. Значение 0, если значение SQLSTATE начинается с 00 (выполнен) или 01 (предупреждение). Значение 1, если SQLSTATE иное.

  • WARNINGS

    Число предупреждений из области диагностики.

  • ROWS_AFFECTED

    Число строк, затронутых запросом. Для описания значения "затронутых" см. раздел 25.8.7.1.

  • ROWS_SENT

    Число строк, возвращенных запросом.

  • ROWS_EXAMINED

    Число строк, прочитанных из механизмов хранения во время выполнения запроса.

  • CREATED_TMP_DISK_TABLES

    Как переменная состояния Created_tmp_disk_tables, но для запроса.

  • CREATED_TMP_TABLES

    Как переменная состояния Created_tmp_tables, но для запроса.

  • SELECT_FULL_JOIN

    Как переменная состояния Select_full_join, но для запроса.

  • SELECT_FULL_RANGE_JOIN

    Как переменная состояния Select_full_range_join, но для запроса.

  • SELECT_RANGE

    Как переменная состояния Select_range, но для запроса.

  • SELECT_RANGE_CHECK

    Как переменная состояния Select_range_check, но для запроса.

  • SELECT_SCAN

    Как переменная состояния Select_scan, но для запроса.

  • SORT_MERGE_PASSES

    Как переменная состояния Sort_merge_passes , но для запроса.

  • SORT_RANGE

    Как переменная состояния a href="server.htm#statvar_Sort_range">Sort_range, но для запроса.

  • SORT_ROWS

    Как переменная состояния Sort_rows, но для запроса.

  • SORT_SCAN

    Как переменная состояния Sort_scan, но для запроса.

  • NO_INDEX_USED

    1, если запрос выполнил сканирование таблицы, не используя индексирование, 0 иначе.

  • NO_GOOD_INDEX_USED

    1, если сервер не нашел индекс, чтобы использовать для запроса, 0 иначе. Для дополнительной информации см. описание столбца Extra из вывода EXPLAIN для значения Range checked for each record разделе 9.8.2.

  • NESTING_EVENT_ID, NESTING_EVENT_TYPE, NESTING_EVENT_LEVEL

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

    Для высокоуровневых запросов:

    OBJECT_TYPE = NULL
    OBJECT_SCHEMA = NULL
    OBJECT_NAME = NULL
    NESTING_EVENT_ID = NULL
    NESTING_EVENT_TYPE = NULL
    NESTING_LEVEL = 0
    

    Для вложенных запросов:

    OBJECT_TYPE = родительский тип объекта запроса
    OBJECT_SCHEMA = родительская схема объекта
    OBJECT_NAME = родительское название объекта
    NESTING_EVENT_ID = EVENT_ID родительского запроса
    NESTING_EVENT_TYPE = 'STATEMENT'
    NESTING_LEVEL = NESTING_LEVEL родительского запроса+1
    

У events_statements_current есть эти индексы:

  • Первичный ключ на (THREAD_ID, EVENT_ID).

TRUNCATE TABLE позволен на events_statements_current. Это удаляет строки.

23.9.6.2. Таблица events_statements_history

events_statements_history содержит N новых событий запроса на поток. Значение N задано при запуске сервера. Чтобы установить табличный размер явно, установите при запуске сервера переменную performance_schema_events_statements_history_size. Событие запроса не добавлено к таблице, пока оно не закончено. Когда новые события добавлены, от более старых событий отказываются, если таблица полна.

events_statements_history имеет ту же структуру, что и events_statements_current. См. раздел 23.9.6.1.

TRUNCATE TABLE позволен на events_statements_history. Это удаляет строки.

23.9.6.3. Таблица events_statements_history_long

events_statements_history_long содержит N новых событий запроса. Значение N задано при запуске сервера. Чтобы установить табличный размер явно, установите при запуске сервера переменную performance_schema_events_statements_history_long_size. События не добавлены к таблице, пока они не закончились. Когда новые события добавлены, от более старых событий отказываются, если таблица полна. Когда поток заканчивается, его строки удалены из таблицы.

events_statements_history_long имеет ту же структуру, что и events_statements_current, но без индексов. См. раздел 23.9.6.1.

TRUNCATE TABLE позволен на events_statements_history_long. Это удаляет строки.

23.9.6.4. Таблица prepared_statements_instances

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

  • Протокол двоичной синхронной передачи данных. К этому получают доступ через MySQL C API, и он отображается на основные команды сервера как показано в следующей таблице.

    Функция C API Соответствующая команда сервера
    mysql_stmt_prepare() COM_STMT_PREPARE
    mysql_stmt_execute() COM_STMT_EXECUTE
    mysql_stmt_close()COM_STMT_CLOSE
  • Текстовый протокол. К этому получают доступ, используя запросы SQL и отображая на основные команды сервера, как показано в следующей таблице.

    SQL-запрос Соответствующая команда сервера
    PREPARE SQLCOM_PREPARE
    EXECUTE SQLCOM_EXECUTE
    DEALLOCATE PREPARE, DROP PREPARE SQLCOM_DEALLOCATE PREPARE

Performance Schema подготовила покрытие инструментовки обоих протоколов. Следующее обсуждение отсылает к командам сервера, а не функциям C API или запросам SQL.

Информация о готовых запросах доступна в таблице prepared_statements_instances. Эта таблица включает просмотр готовых запросов, используемых в сервере, и обеспечивает соединенную статистику о них. Чтобы управлять размером этой таблицы, установите при запуске сервера системную переменную performance_schema_max_prepared_statements_instances.

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

ИнструментКоманда сервера
statement/com/Prepare COM_STMT_PREPARE
statement/com/Execute COM_STMT_EXECUTE
statement/sql/prepare_sql SQLCOM_PREPARE
statement/sql/execute_sql SQLCOM_EXECUTE

Performance Schema управляет содержанием prepared_statements_instances следующим образом:

  • Подготовка запроса.

    Команда COM_STMT_PREPARE или SQLCOM_PREPARE создает готовый запрос в сервере. Если запрос успешно инструментован, новая строка добавлена к prepared_statements_instances. Если запрос не может быть инструментован, увеличена переменная Performance_schema_prepared_statements_lost.

  • Выполнение готового запроса.

    Выполнение команды COM_STMT_EXECUTE или SQLCOM_PREPARE для инструментованного готового случая запроса обновляет соответствующую строку таблицы prepared_statements_instances.

  • Освобождение готового запроса.

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

У prepared_statements_instances есть эти столбцы:

  • OBJECT_INSTANCE_BEGIN

    Адрес в памяти инструментованного готового запроса.

  • STATEMENT_ID

    Внутренний ID, назначенный сервером.

  • STATEMENT_NAME

    Для протокола двоичной синхронной передачи данных этот столбец NULL. Для текстового протокола этот столбец внешнее имя, назначенное пользователем. Например, для следующего запроса SQL, название готового запроса stmt:

    PREPARE stmt FROM 'SELECT 1';
    
  • SQL_TEXT

    Готовый текст запроса с маркерами заполнителями ?.

  • OWNER_THREAD_ID, OWNER_EVENT_ID

    Эти столбцы указывают на событие, которое создало готовый запрос.

  • OWNER_OBJECT_TYPE, OWNER_OBJECT_SCHEMA, OWNER_OBJECT_NAME

    Для готового запроса, создаваемого сеансом клиента, эти столбцы NULL. Для готового запроса, создаваемого сохраненной программой, эти столбцы указывают на сохраненную программу. Типичная пользовательская ошибка в том, что пользователь забывает освобождать подготовленные запросы. Эти столбцы могут использоваться, чтобы найти сохраненные программы, которые пропускают готовые запросы:

    SELECT OWNER_OBJECT_TYPE, OWNER_OBJECT_SCHEMA, OWNER_OBJECT_NAME,
           STATEMENT_NAME, SQL_TEXT
           FROM performance_schema.prepared_statements_instances
           WHERE OWNER_OBJECT_TYPE IS NOT NULL;
    
  • TIMER_PREPARE

    Время на выполнение подготовки запроса.

  • COUNT_REPREPARE

    Сколько раз запрос был повторно подготовлено внутренне (см. раздел 9.10.4). Статистические данные синхронизации для переподготовки недоступны, потому что это посчитано как часть выполнения запроса, не как отдельная работа.

  • COUNT_EXECUTE, SUM_TIMER_EXECUTE, MIN_TIMER_EXECUTE, AVG_TIMER_EXECUTE, MAX_TIMER_EXECUTE

    Соединенная статистика для выполнения готового запроса.

  • SUM_xxx

    Остающееся столбцы SUM_xxx то же самое, что касается сводных таблиц запросов (см. раздел 23.9.15.3).

У prepared_statements_instances есть эти индексы:

  • Первичный ключ на (OBJECT_INSTANCE_BEGIN).

  • Индекс на (STATEMENT_ID).
  • Индекс на (STATEMENT_NAME).
  • Индекс на (OWNER_THREAD_ID, OWNER_EVENT_ID).
  • Индекс на (OWNER_OBJECT_TYPE, OWNER_OBJECT_SCHEMA, OWNER_OBJECT_NAME).

TRUNCATE TABLE сбрасывает столбцы статистики prepared_statements_instances.

23.9.7. Операционные таблицы Performance Schema

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

Операционная конфигурация событий

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

setup_instruments содержит инструмент transaction. Этот инструмент отключен по умолчанию:

mysql> SELECT * FROM setup_instruments WHERE NAME = 'transaction';
+-------------+---------+-------+
| NAME        | ENABLED | TIMED |
+-------------+---------+-------+
| transaction | NO      | NO    |
+-------------+---------+-------+

Чтобы включить сбор операционных событий, включая информацию о синхронизации:

mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'
                 WHERE NAME = 'transaction';

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

mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%transactions%';
+----------------------------------+---------+
| NAME                             | ENABLED |
+----------------------------------+---------+
| events_transactions_current      | NO      |
| events_transactions_history      | NO      |
| events_transactions_history_long | NO      |
+----------------------------------+---------+

Чтобы включить всех операционных потребителей:

mysql> UPDATE setup_consumers SET ENABLED = 'YES'
                 WHERE NAME LIKE '%transactions%';

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

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

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

Чтобы изменить модуль синхронизации, измените TIMER_NAME:

mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'
                 WHERE NAME = 'transaction';

Операционные границы

В MySQL Server транзакции запускаются явно с этих запросов:

START TRANSACTION | BEGIN | XA START | XA BEGIN

Транзакции также запускаются неявно. Например, когда включена переменная autocommit, запуск каждого запроса запускает новую транзакцию.

Если autocommit выключена, первый запрос после переданной транзакции отмечает запуск новой транзакции. Последующие запросы это часть транзакции, пока это не передано.

Транзакции явно заканчиваются этими запросами:

COMMIT | ROLLBACK | XA COMMIT | XA ROLLBACK

Транзакции также заканчиваются неявно, выполнением запросов DDL, запросами блокировки и запросами администрирования сервера.

В следующем обсуждении ссылки на START TRANSACTION также применимы к BEGIN, XA START и XA BEGIN. Точно так же ссылки на COMMIT и ROLLBACK относятся к XA COMMIT и XA ROLLBACK.

Performance Schema определяет операционные границы аналогично серверу. Запуск и конец операционного случая близко соответствуют соответствующим изменениям состояния в сервере:

  • Для явно запущенной транзакции операционный случай запускается во время обработки START TRANSACTION.

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

Есть тонкие значения к этому подходу:

  • Операционные события в Performance Schema не полностью включают события запроса, связанные с передачей START TRANSACTION, COMMIT или ROLLBACK. Есть тривиальное количество перекрытия синхронизации между операционным случаем и этими запросыми.

  • Запросы, которые работают с нетранзакционными механизмами, не имеют никакого эффекта на операционное состояние соединения. Для неявных транзакций операционный случай начинается с первого запроса, который использует транзакционный механизм. Это означает, что запросы, воздействующие исключительно на нетранзакционные таблицы, проигнорированы, даже после START TRANSACTION.

Чтобы иллюстрировать, рассмотрите следующий сценарий:

1. SET autocommit = OFF;
2. CREATE TABLE t1 (a INT) ENGINE = InnoDB;
3. START TRANSACTION; -- Transaction 1 START
4. INSERT INTO t1 VALUES (1), (2), (3);
5. CREATE TABLE t2 (a INT) ENGINE = MyISAM; -- Transaction 1 COMMIT
  -- (implicit; DDL forces commit)
6. INSERT INTO t2 VALUES (1), (2), (3); -- Update nontransactional table
7. UPDATE t2 SET a = a + 1; -- ... and again
8. INSERT INTO t1 VALUES (4), (5), (6); -- Write to transactional table
  -- Transaction 2 START (implicit)
9. COMMIT;-- Transaction 2 COMMIT

С точки зрения сервера, транзакция 1 завершилась, когда таблица t2 создается. Транзакция 2 не запускается, пока к транзакционный таблице не получают доступ, несмотря на прошедшие обновления нетранзакционных таблиц.

С точки зрения Performance Schema, транзакция 2 запускается, когда сервер переходит в активное состояние транзакции. Запросы 6 и 7 не включены в пределы границ транзакции 2, которые совместимы с тем, как сервер пишет транзакции в двоичный журнал.

Операционная инструментовка

Три признака определяют транзакции:

  • Режим доступа (только для чтения, чтение-запись).

  • Уровень изоляции ( SERIALIZABLE, REPEATABLE READ, и т.д.).
  • Неявная (включен autocommit ) или явная (выключен autocommit).

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

Чтобы выборочно исследовать операционную историю, используйте столбцы признака в операционных таблицах событий: ACCESS_MODE, ISOLATION_LEVEL и AUTOCOMMIT.

Стоимость операционной инструментовки может быть уменьшена различными путями, такими как включение или отключение операционной инструментовки, согласно пользователю, учетной записи, узлу или потоку (соединению клиента).

Транзакции и вложенные события

Родитель операционного случая это случай, который начал транзакцию. Для явно запущенной транзакции это включает START TRANSACTION и COMMIT AND CHAIN. Для неявно запущенной транзакции это первый запрос, который использует транзакционный механизм после того, как предыдущая транзакция заканчивается.

Вообще, транзакция высокоуровневый родитель ко всем событиям, начатым во время транзакции, включая запросы, которые явно заканчивают транзакцию, такие как COMMIT и ROLLBACK. Исключения: запросы, которые неявно заканчивают транзакцию, такие как запросы DDL, когда текущая транзакция должна быть закрыта прежде, чем новый запрос выполнен.

Транзакции и сохраненные программы

Транзакции и сохраненные события программы связаны следующим образом:

  • Хранимые процедуры.

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

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

    Если транзакция запущена хранимой процедурой, хранимая процедура родитель операционного случая.

  • Сохраненные функции.

    Сохраненные функции ограничены от порождения явной или неявной передачи или отмены транзакции. Сохраненные функциональные события могут находиться в пределах родительского операционного случая.

  • Триггеры.

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

    Триггеры не могут сделать запросы, которые вызывают явную или неявную передают или отмену транзакции.

  • Запланированные события.

    Выполнение запросов в теле запланированного события имеет место в новом соединении. Вложение запланированного события в пределы родительской транзакции неприменимо.

Транзакции и Savepoints

Запросы Savepoint зарегистрированы как отдельные события. Операционные события включают отдельные счетчики для SAVEPOINT, ROLLBACK TO SAVEPOINT и RELEASE SAVEPOINT, которые произошли во время транзакции.

Транзакции и ошибки

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

23.9.7.1. Таблица events_transactions_current

events_transactions_current содержит текущие операционные события, одну строку на поток, показывая текущий статус нового отслеживающего потока. Например:

mysql> SELECT * FROM events_transactions_current LIMIT 1\G
*************************** 1. row ***************************
THREAD_ID: 26
 EVENT_ID: 7
 END_EVENT_ID: NULL
   EVENT_NAME: transaction
  STATE: ACTIVE
 TRX_ID: NULL
   GTID: 3E11FA47-71CA-11E1-9E33-C80AA9429562:56
XID: NULL
 XA_STATE: NULL
 SOURCE: transaction.cc:150
  TIMER_START: 420833537900000
TIMER_END: NULL
   TIMER_WAIT: NULL
  ACCESS_MODE: READ WRITE
ISOLATION_LEVEL: REPEATABLE READ
   AUTOCOMMIT: NO
 NUMBER_OF_SAVEPOINTS: 0
NUMBER_OF_ROLLBACK_TO_SAVEPOINT: 0
NUMBER_OF_RELEASE_SAVEPOINT: 0
OBJECT_INSTANCE_BEGIN: NULL
   NESTING_EVENT_ID: 6
 NESTING_EVENT_TYPE: STATEMENT

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

У events_transactions_current есть эти столбцы:

  • THREAD_ID, EVENT_ID

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

  • END_EVENT_ID

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

  • EVENT_NAME

    Название инструмента, у которого был собран случай. Это NAME из setup_instruments . Инструментальные имена могут иметь много частей и сформировать иерархию, как обсуждено в разделе 23.4.

  • STATE

    Текущее операционное состояние. Значение ACTIVE (после START TRANSACTION или BEGIN), COMMITTED (после COMMIT) или ROLLED BACK (после ROLLBACK).

  • TRX_ID

    Не использован.

  • GTID

    Столбец GTID содержит значение gtid_next, которое может быть одним из ANONYMOUS, AUTOMATIC или GTID с использованием формата UUID:NUMBER. Для транзакций с использованием gtid_next=AUTOMATIC (это все нормальные транзакции клиента), столбец GTID меняется, когда транзакция завершается и фактический GTID назначен. Если gtid_mode ON или ON_PERMISSIVE, столбец GTID изменяется на GTID транзакции. Если gtid_mode OFF или OFF_PERMISSIVE, столбец GTID изменяется на ANONYMOUS.

  • XID_FORMAT_ID, XID_GTRID, XID_BQUAL

    Компоненты операционного идентификатора XA. Их формат описан в разделе 14.3.7.1.

  • XA_STATE

    Состояние транзакции XA. Значение ACTIVE (после XA START), IDLE (после XA END), PREPARED (после XA PREPARE), ROLLED BACK (после XA ROLLBACK) или COMMITTED (после XA COMMIT).

  • SOURCE

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

  • TIMER_START, TIMER_END, TIMER_WAIT

    Информация о синхронизации для случая. Модуль для этих значений пикосекунды. TIMER_START и TIMER_END указывают, когда синхронизация событий запустилась и закончилась. TIMER_WAIT продолжительность.

    Если случай не закончился, TIMER_END текущее значение таймера и TIMER_WAIT время, законченное до сих пор (TIMER_END - TIMER_START).

    Если случай произведен из инструмента, который имеет TIMED = NO, информация синхронизации не собрана, и TIMER_START, TIMER_END и TIMER_WAIT NULL.

  • ACCESS_MODE

    Операционный режим доступа. Значение READ ONLY или READ WRITE.

  • ISOLATION_LEVEL

    Операционный уровень изоляции. Значение REPEATABLE READ , READ COMMITTED , READ UNCOMMITTED или SERIALIZABLE.

  • AUTOCOMMIT

    Был ли режим autcommit включен, когда транзакция запускалась.

  • NUMBER_OF_SAVEPOINTS, NUMBER_OF_ROLLBACK_TO_SAVEPOINT, NUMBER_OF_RELEASE_SAVEPOINT

    Число запросов SAVEPOINT, ROLLBACK TO SAVEPOINT и RELEASE SAVEPOINT во время транзакции.

  • OBJECT_INSTANCE_BEGIN

    Не использован.

  • NESTING_EVENT_ID

    EVENT_ID случая, в пределах которого вложен этот случай.

  • NESTING_EVENT_TYPE

    Тип вложения событий. Значение TRANSACTION, STATEMENT, STAGE или WAIT. TRANSACTION не будет появляться, потому что транзакции не могут быть вложены.

У events_transactions_current есть эти индексы:

  • Первичный ключ на (THREAD_ID, EVENT_ID).

TRUNCATE TABLE позволен на events_transactions_current. Это удаляет строки.

23.9.7.2. Таблица events_transactions_history

Таблица events_transactions_history хранит N последних операционных событий на поток. Значение N задано при запуске сервера. Чтобы установить табличный размер явно, установите системную переменную performance_schema_events_transactions_history_size при запуске сервера. Операционные события не добавлены к таблице, пока они не закончены. Когда новые события добавлены, от более старых событий отказываются, если таблица полна.

Таблица events_transactions_history имеет ту же самую структуру, как events_transactions_current, включая индексацию. См. раздел 23.9.7.1.

TRUNCATE TABLE позволен на events_transactions_history. Это удаляет строки.

23.9.7.3. Таблица events_transactions_history_long

Таблица events_transactions_history_long хранит N новых операционных событий. Значение N задано при запуске сервера. Чтобы установить табличный размер явно, установите при запуске сервера системную переменную performance_schema_events_transactions_history_long_size. Операционные события не добавлены к таблице, пока они не закончены. Когда новые события добавлены, от более старых событий отказываются, если таблица полна. Когда поток заканчивается, его строки удалены из таблицы.

У events_transactions_history_long та же самая структура, как у events_transactions_current, за исключением того, что это не имеет индексов. См. раздел 23.9.7.1.

TRUNCATE TABLE позволен на events_transactions_history_long. Это удаляет строки.

23.9.8. Таблицы соединения Performance Schema

Когда клиент соединяется с сервером MySQL, он делает это под именем пользователя и от конкретного узла. Performance Schema обеспечивает статистику об этих соединениях, отслеживая их для учетной записи (комбинация пользователя и узла), а также отдельно для имени пользователя и имени хоста, используя эти таблицы:

  • accounts: Статистика соединения по учетной записи клиента.

  • hosts: Статистика соединения по имени хоста клиента.
  • users: Статистика соединения по имени пользователя клиента.

Значение account в таблицах соединения подобно его значению в таблицах привилегий MySQL базы данных mysql, в том смысле, что термин относится к комбинации значений узла и пользователя. Они отличаются в том, что для таблиц привилегий часть узла учетной записи может быть образцом, тогда как для Performance Schema значение узла всегда определенное имя хоста.

Каждая таблица соединения имеет столбцы CURRENT_CONNECTIONS и TOTAL_CONNECTIONS, чтобы отследить текущее и общее количество соединений за преиод слежения на котором базируются статистические данные. Таблицы отличаются по тому, что они используют для значения отслеживания. Таблица accounts имеет столбцы USER и HOST, чтобы отследить соединения на комбинацию пользователя и узла. users и hosts имеют столбцы USER и HOST, соответственно, чтобы отследить соединения за имя пользователя и имя хоста.

Performance Schema также считает внутренние потоки и потоки для пользовательских сеансов, которые были не в состоянии подтвердить подлинность, используя строки со столбцами USER и HOST NULL.

Предположите, что клиенты user1 и user2 соединились с машин hosta и hostb. Performance Schema отслеживает соединения следующим образом:

  • Таблица accounts имеет четыре строки, считая одно соединение за учетную запись, для user1/hosta, user1/hostb, user2/hosta и user2/hostb.

  • Таблица hosts имеет имеет две строки для hosta и hostb, считая два соединения на имя хоста.
  • Таблица users имеет две строки для user1 и user2, считая два соединения на имя пользователя.

Когда клиент соединяется, Performance Schema определяет, какая строка в каждой таблице соединения применяется, используя значение отслеживания, соответствующее каждой таблице. Если нет такой строки, она добавлена. Тогда Performance Schema постепенно увеличивает столбцы CURRENT_CONNECTIONS и TOTAL_CONNECTIONS в этой строке.

Когда клиент разъединяется, Performance Schema уменьшает столбец CURRENT_CONNECTIONS в строке и не меняет столбец TOTAL_CONNECTIONS.

TRUNCATE TABLE позволен на таблицах соединения. Это имеет эффекты:

  • Строки удалены для учетных записей, узлов или пользователей, у которых нет никаких текущих соединений (строки с CURRENT_CONNECTIONS = 0).

  • Неудаленные строки сброшены, чтобы посчитать только текущие соединения: для строк с CURRENT_CONNECTIONS > 0, TOTAL_CONNECTIONS сброшен к CURRENT_CONNECTIONS.
  • Сводные таблицы, которые зависят от таблицы соединения, являются неявно усеченными, как описано позже в этом разделе.

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

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
                 WHERE TABLE_SCHEMA = 'performance_schema' AND
                 TABLE_NAME REGEXP '_summary_by_(account|host|user)'
                 ORDER BY TABLE_NAME;
+------------------------------------------------------+
| TABLE_NAME |
+------------------------------------------------------+
| events_errors_summary_by_account_by_error|
| events_errors_summary_by_host_by_error   |
| events_errors_summary_by_user_by_error   |
| events_stages_summary_by_account_by_event_name |
| events_stages_summary_by_host_by_event_name|
| events_stages_summary_by_user_by_event_name|
| events_statements_summary_by_account_by_event_name   |
| events_statements_summary_by_host_by_event_name|
| events_statements_summary_by_user_by_event_name|
| events_transactions_summary_by_account_by_event_name |
| events_transactions_summary_by_host_by_event_name|
| events_transactions_summary_by_user_by_event_name|
| events_waits_summary_by_account_by_event_name  |
| events_waits_summary_by_host_by_event_name |
| events_waits_summary_by_user_by_event_name |
| memory_summary_by_account_by_event_name  |
| memory_summary_by_host_by_event_name |
| memory_summary_by_user_by_event_name |
+------------------------------------------------------+

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

TRUNCATE TABLE позволен на сводных таблицах соединения. Это удаляет строки для учетных записей, узлов или пользователей без соединений и сбрасывает сводные столбцы к нолю для остающихся строк. Кроме того, каждая сводная таблица, которая собирает данные соединения по учетной записи, узлу, пользователю или потоку, неявно усечена усечением таблицы соединения, от которой зависит. Следующая таблица описывает отношения между табличным усечением соединения и неявно усеченными таблицами.

Таблица 23.2. Неявные эффекты табличного усечения соединения

Усеченная таблица соединения Неявно усеченные сводные таблицы
accounts Таблицы с именами, содержащими _summary_by_account, _summary_by_thread
hosts Таблицы с именами, содержащими _summary_by_account, _summary_by_host, _summary_by_thread
users Таблицы с именами, содержащими _summary_by_account, _summary_by_user, _summary_by_thread

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

23.9.8.1. Таблица accounts

Таблица accounts содержит строку для каждой учетной записи, которая соединилась с сервером MySQL. Для каждой учетной записи таблица считает текущее и общее количество соединений. Табличный размер задан при запуске сервера. Чтобы установить табличный размер явно, установите системную переменную performance_schema_accounts_size при запуске сервера. Чтобы отключить статистику учетной записи, установите эту переменную в 0.

Таблица accounts имеет следующие столбцы. Для описания того, как Performance Schema поддерживает строки в этой таблице, включая эффект TRUNCATE TABLE, см. раздел 23.9.8.

  • USER

    Имя пользователя клиента для соединения. Это NULL для внутреннего потока или для пользовательского сеанса, который был не в состоянии подтвердить подлинность.

  • HOST

    Узел, с которого соединялся клиент. Это NULL для внутреннего потока или для пользовательского сеанса, который был не в состоянии подтвердить подлинность.

  • CURRENT_CONNECTIONS

    Текущее число соединений для учетной записи.

  • TOTAL_CONNECTIONS

    Общее количество соединений для учетной записи.

У accounts есть эти индексы:

  • Первичный ключ на (USER, HOST).

23.9.8.2. Таблица hosts

Таблица hosts содержит строку для каждого узла, с которого клиенты соединились с сервером MySQL. Для каждого имени хоста таблица считает текущее и общее количество соединений. Табличный размер задан при запуске сервера. Чтобы установить табличный размер явно, установите системную переменную performance_schema_hosts_size при запуске сервера. Чтобы отключить статистику учетной записи, установите эту переменную в 0.

Таблица hosts имеет следующие столбцы. Для описания того, как Performance Schema поддерживает строки в этой таблице, включая эффект TRUNCATE TABLE, см. раздел 23.9.8.

  • HOST

    Узел, от которого соединялся клиент. Это NULL для внутреннего потока или для пользовательского сеанса, который был не в состоянии подтвердить подлинность.

  • CURRENT_CONNECTIONS

    Текущее число соединений для учетной записи.

  • TOTAL_CONNECTIONS

    Общее количество соединений для учетной записи.

У hosts есть эти индексы:

  • Первичный ключ на (HOST).

23.9.8.3. Таблица users

Таблица users содержит строку для каждого пользователя, который соединился с сервером MySQL. Для каждого имени пользователя таблица считает текущее и общее количество соединений. Табличный размер задан при запуске сервера. Чтобы установить табличный размер явно, установите переменную performance_schema_users_size при запуске сервера. Чтобы отключить пользовательскую статистику, установите эту переменную в 0.

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

  • HOST

    Узел, от которого соединялся клиент. Это NULL для внутреннего потока или для пользовательского сеанса, который был не в состоянии подтвердить подлинность.

  • CURRENT_CONNECTIONS

    Текущее число соединений для учетной записи.

  • TOTAL_CONNECTIONS

    Общее количество соединений для учетной записи.

У users есть эти индексы:

  • Первичный ключ на (USER).

23.9.9. Таблицы атрибутов соединения Performance Schema

Приложения могут предоставить пары ключ/значение как атрибуты соединения для передачи серверу во время соединения. Для C API определите набор признака, используя функции mysql_options() и mysql_options4(). Другие MySQL Connector могут обеспечить свои собственные методы определения.

Эти таблицы выставляют информацию атрибута:

  • session_account_connect_attrs: Признаки соединения для текущего сеанса и других сеансов, связанных с учетной записью сеанса.

  • session_connect_attrs: Признаки соединения для всех сеансов.

Названия атрибутов, которые начинаются с подчеркивания (_), сохранены для внутреннего пользования и не должен быть созданы приложениями. Это соглашение разрешает новым признакам быть введенными MySQL, не сталкиваясь с признаками приложения.

Набор признаков соединения, видимых в данном соединении, изменяется в зависимости от Вашей платформы и MySQL Connector, которым установили соединение.

Библиотека клиента libmysqlclient (обеспечена в MySQL и MySQL Connector/C) устанавливает эти признаки:

  • _client_name: Имя клиента (libmysql для библиотеки клиента).

  • _client_version: Версия библиотеки клиента.
  • _os: Операционная система (например, Linux, Win64).
  • _pid: ID процесса клиента.
  • _platform: Машинная платформа (например, x86_64).
  • _thread: ID потока клиента (только под Windows).

Прочие MySQL Connector могут определить свои собственные признаки соединения.

MySQL Connector/J определяет эти признаки:

  • _client_license: Тип лицензии соединителя.

  • _runtime_vendor: Поставщик Java runtime environment (JRE).
  • _runtime_version: Версия Java runtime environment (JRE).

MySQL Connector/Net определяет эти признаки:

  • _client_version: Версия библиотеки клиента.

  • _os: Операционная система (например, Linux, Win64).
  • _pid: ID процесса клиента.
  • _platform: Машинная платформа (например, x86_64).
  • _program_name: Имя клиента.
  • _thread: ID потока клиента (только под Windows).

PHP определяет признаки, которые зависят от того, как он был собран:

  • Собран с применением libmysqlclient: признаки libmysqlclient, описанные ранее.

  • Собран с применением mysqlnd: только признак _client_name со значением mysqlnd.

Много программ клиента MySQL устанавливают признак program_name со значением, равным имени клиента. Например, mysqladmin и mysqldump устанавливают program_name в mysqladmin и mysqldump, соответственно.

Некоторые программы клиента MySQL определяют дополнительные признаки:

  • mysqlbinlog определяет _client_role как binary_log_listener.

  • Ведомые соединения репликации определяют program_name как mysqld, _client_role как binary_log_listener и _client_replication_channel_name как название канала.
  • Соединения механизма хранения FEDERATED определяют program_name как mysqld и _client_role как federated_storage.

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

Для соединений, начатых, используя C API, библиотека libmysqlclient налагает предел 64 КБ на совокупный размер данных о признаке соединения по стороне клиента: вызовы mysql_options(), которые превышают этот предел, производят ошибку CR_INVALID_PARAMETER_NO. Другие MySQL Connector могут наложить свои собственные клиентские пределы на то, сколько данных о признаке соединения может быть передано серверу.

На стороне сервера данные о признаке соединения проверяются так:

  • Сервер налагает предел 64 КБ на совокупный размер данных о признаке соединения, который примет. Если клиент пытается послать больше 64 КБ данных о признаке, сервер отклоняет соединение. Иначе, сервер полагает, что признак допустимый и отслеживает размер самого длинного буфера признака в статусной переменной Performance_schema_session_connect_attrs_longest_seen.

  • Для принятых соединений Performance Schema проверяет совокупный размер признака по значению переменной performance_schema_session_connect_attrs_size. Если размер признака превышает это значение, эти действия имеют место:

    • Performance Schema усекает данные о признаке и увеличивает переменную Performance_schema_session_connect_attrs_lost, которая указывает число соединений, для которых произошло усечение признака.

    • Performance Schema пишет сообщение в журнал ошибок, если log_warnings больше, чем ноль:
      Connection attributes of length N were truncated (N bytes lost)
      for connection N, user
      user_name@host_name
      (as user_name), auth: {yes|no}
      

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

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

23.9.9.1. Таблица session_account_connect_attrs

Приложения могут обеспечить признаки соединения ключа/значения, которые передадут к серверу во время соединения, используя функции C API the mysql_options() и mysql_options4().

session_account_connect_attrs содержит признаки соединения только для сеансов для Вашей собственной учетной записи. Чтобы видеть признаки соединения для всех сеансов, загляните в session_connect_attrs .

У session_account_connect_attrs есть эти столбцы:

  • PROCESSLIST_ID

    Идентификатор соединения для сеанса.

  • ATTR_NAME

    Название атрибута.

  • ATTR_VALUE

    Значение атрибута.

  • ORDINAL_POSITION

    Порядок, в котором признак был добавлен к набору признаков соединения.

У session_account_connect_attrs есть эти индексы:

  • Первичный ключ на (PROCESSLIST_ID, ATTR_NAME).

TRUNCATE TABLE не позволен для session_account_connect_attrs.

23.9.9.2. Таблица session_connect_attrs

Приложения могут обеспечить признаки соединения ключа/значения, которые передадут серверу во время соединения, используя функции C API the mysql_options() и mysql_options4().

session_connect_attrs содержит признаки соединения для всех сеансов. Чтобы видеть признаки соединения сеансов только для Вашей собственной учетной записи, загляните в session_account_connect_attrs.

У session_connect_attrs есть эти столбцы:

  • PROCESSLIST_ID

    Идентификатор соединения для сеанса.

  • ATTR_NAME

    Название атрибута.

  • ATTR_VALUE

    Значение атрибута.

  • ORDINAL_POSITION

    Порядок, в котором признак был добавлен к набору признаков соединения.

У session_connect_attrs есть эти индексы:

  • Первичный ключ на (PROCESSLIST_ID, ATTR_NAME).

TRUNCATE TABLE не позволен для session_connect_attrs.

23.9.10. Таблицы пользовательских переменных Performance Schema

Performance Schema обеспечивает таблицу user_variables_by_thread, которая выставляет определяемые пользователем переменные. Это переменные, определенные в пределах определенного сеанса, и включают символ @, предшествующий имени.

У user_variables_by_thread есть эти столбцы:

  • THREAD_ID

    Идентификатор потока сеанса, в котором определена переменная.

  • VARIABLE_NAME

    Имя переменной без символа @.

  • VARIABLE_VALUE

    Значение переменной.

У user_variables_by_thread есть эти индексы:

  • Первичный ключ на (THREAD_ID, VARIABLE_NAME).

TRUNCATE TABLE не позволен для user_variables_by_thread.

23.9.11. Таблицы репликации Performance Schema

Performance Schema обеспечивает таблицы, которые выставляют информацию о репликации. Это подобно информации, доступной от SHOW SLAVE STATUS, но представление в табличной форме более доступно и обладает преимуществами удобства и простоты использования:

  • Вывод SHOW SLAVE STATUS полезен для визуального осмотра, но не для использования с программным управлением. В отличие от этого, используя таблицы Performance Schema, информация о ведомом состоянии может искаться, используя общие запросы SELECT, включая комплексные условия WHERE, соединения и т.д.

  • Результаты запроса могут быть сохранены в таблицах для дальнейшего анализа или назначены переменным и таким образом использоваться в хранимых процедурах.
  • Таблицы репликации предоставляют лучшую диагностическую информацию. Для мультипоточной ведомой работы SHOW SLAVE STATUS показывает все ошибки потоков, используя поля Last_SQL_Errno и Last_SQL_Error, таким образом, только последняя из этих ошибок видима, и информация может быть потеряна. Таблицы репликации хранят ошибки на основе потока без потери информации.
  • Последняя замеченная транзакция видима в таблицах. Эта информация недоступна из SHOW SLAVE STATUS .
  • Разработчики, знакомые с интерфейсом Performance Schema, могут расширить таблицы, чтобы обеспечить дополнительную информацию, добавляя строки к таблицам.

Описание таблиц репликации

Performance Schema обеспечивает несколько связанных таблиц:

  • Таблицы, которые содержат информацию о присоединении ведомого сервера к главному серверу:

  • Таблицы, которые содержат общую (не определенную для потока) информацию о транзакци:

  • Таблицы, которые содержат информацию об определенных потоках, ответственных за применение транзакций, полученных от ведущего устройства:

  • Таблицы, которые содержат информацию о членах группы:

    • replication_group_members: Предоставляет сетевую и информацию о статусе членов группы.

    • replication_group_member_stats: Предоставляет статистическую информацию о членах группы и транзакции, в которой они участвуют.

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

Остаток этого введения в таблицы описывает, как Performance Schema заполняет их, и которые области от SHOW SLAVE STATUS не представлены в таблицах.

Жизненный цикл таблиц

Performance Schema заполняет таблицы следующим образом:

  • До выполнения CHANGE MASTER TO таблицы пусты.

  • После CHANGE MASTER TO параметры конфигурации могут быть замечены в таблицах. В это время нет никаких активных ведомых потоков, таким образом, столбцы THREAD_ID NULL и SERVICE_STATE OFF.
  • После START SLAVE, THREAD_ID не NULL. У потоков, которые спят или активны, есть SERVICE_STATE ON. У потока, который соединяется с главным сервером, есть значение CONNECTING в то время, как это устанавливает соединение, и ON после этого, пока соединение длится.
  • После STOP SLAVE THREAD_ID NULL и у столбцов SERVICE_STATE для потоков, которые больше не существуют, OFF.
  • Таблицы сохранены после STOP SLAVE или потоков с ошибками.
  • Таблица replication_applier_status_by_worker непуста только, когда ведомое устройство работает в виде мультидерева сообщений. Таким образом, если системная переменная slave_parallel_workers больше 0, эта таблица заполнена, когда выполнен START SLAVE, число строк показывает количество рабочих процессов.

Информация SHOW SLAVE STATUS не в таблицах репликации

Информация в таблицах Performance Schema несколько отличается от информации, доступной от SHOW SLAVE STATUS потому? что таблицы ориентируются на использование глобальных операционных идентификаторов (GTID), а не имен файла и позиций, и они представляют серверные значения UUID, а не значения ID сервера. Из-за этих различий, несколько столбцов SHOW SLAVE STATUS не сохранены в Performance Schema или представлены иным путем:

  • Следующие области обращаются к именам файла и позициям и не сохранены:

    Master_Log_File
    Read_Master_Log_Pos
    Relay_Log_File
    Relay_Log_Pos
    Relay_Master_Log_File
    Exec_Master_Log_Pos
    Until_Condition
    Until_Log_File
    Until_Log_Pos
    
  • Поле Master_Info_File не сохранено. Это обращается к файлу master.info, который был заменен безопасными для катастрофического отказа ведомыми таблицами.
  • Следующие области основаны на server_id, а не server_uuid и не сохранены:
    Master_Server_Id
    Replicate_Ignore_Server_Ids
    
  • Поле Skip_Counter основано на количестве событий, а не GTID и не сохранено.
  • Эти ошибочные поля псевдонимы для Last_SQL_Errno и Last_SQL_Error, таким образом, они не сохранены:
    Last_Errno
    Last_Error
    

    В Performance Schema эта информация об ошибке доступна в столбцах LAST_ERROR_NUMBER и LAST_ERROR_MESSAGE таблицы replication_applier_status_by_coordinator replication_applier_status_by_worker, если ведомое устройство является мультипоточным). Те таблицы предоставляют более определенную информацию об ошибке для потока, чем доступна от Last_Errno и Last_Error.

  • Области, которые предоставляют информацию об опциях фильтрации командной строки, не сохранены:
    Replicate_Do_DB
    Replicate_Ignore_DB
    Replicate_Do_Table
    Replicate_Ignore_Table
    Replicate_Wild_Do_Table
    Replicate_Wild_Ignore_Table
    
  • Поля Slave_IO_State и Slave_SQL_Running_State не сохранены. Если нужно, эти значения могут быть получены из списка процессов при использовании столбца THREAD_ID соответствующей таблицы и присоединения к этому столбца ID таблицы INFORMATION_SCHEMA PROCESSLIST, чтобы выбрать столбец STATE последней таблицы.
  • Поле Executed_Gtid_Set может показать большой набор с большим количеством текста. Вместо этого таблицы Performance Schema показывают GTID транзакций, которые в настоящее время применяются ведомым устройством. Альтернативно, набор выполненного GTID может быть получен из значения переменной gtid_executed.
  • Seconds_Behind_Master и Relay_Log_Space не сохранены.

Переменные состояния, перемещенные в таблицы

Начиная с MySQL 5.7.5, следующие переменные состояния (ранее доступные через использование SHOW STATUS ) были перемещены в таблицы Perfomance Schema:

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

Каналы репликации

Первый столбец таблиц Performance Schema CHANNEL_NAME. Это позволяет таблицам рассматриваться по каналам. Когда Вы используете многократные каналы на ведомом устройстве, Вы можете фильтровать таблицы по каналам, чтобы контролировать определенный канал. См. разделы 19.2.3 и 19.1.4.3.

23.9.11.1. Таблица replication_connection_configuration

Эта таблица показывает параметры конфигурации, используемые ведомым сервером для того, чтобы соединиться с главным сервером. Параметры, сохраненные в таблице, могут быть изменены во время выполнения с помощью CHANGE MASTER TO, как обозначено в описаниях столбца.

По сравнению с replication_connection_status, replication_connection_configuration изменяется менее часто. Это содержит значения, которые определяют, как ведомое устройство соединяется с ведущим и которые остаются постоянными во время соединения, тогда как replication_connection_status содержит значения, которые изменяются во время соединения.

У replication_connection_configuration есть эти столбцы:

  • CHANNEL_NAME

    Канал, который эта строка отображает. Всегда есть канал по умолчанию, и больше каналов может быть добавлено. См. раздел 19.2.3.

  • HOST

    Основной узел, с которым соединено ведомое устройство. (CHANGE MASTER TO опция MASTER_HOST).

  • PORT

    Порт для связи с ведущим устройством. (CHANGE MASTER TO опция MASTER_PORT).

  • USER

    Имя пользователя учетной записи для связи с ведущим устройством. (CHANGE MASTER TO опция MASTER_USER).

  • NETWORK_INTERFACE

    Сетевой интерфейс для связи, если есть. (CHANGE MASTER TO опция MASTER_BIND).

  • AUTO_POSITION

    1, если авторасположение используется, иначе 0. (CHANGE MASTER TO опция MASTER_AUTO_POSITION).

  • SSL_ALLOWED, SSL_CA_FILE, SSL_CA_PATH, SSL_CERTIFICATE, SSL_CIPHER, SSL_KEY, SSL_VERIFY_SERVER_CERTIFICATE, SSL_CRL_FILE, SSL_CRL_PATH

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

    SSL_ALLOWED имеет эти значения:

    • Yes если соединение SSL с ведущим устройством разрешено.

    • No, если соединение SSL с ведущим устройством не разрешено.
    • Ignored, если соединение SSL разрешено, но у ведомого сервера нет включенной поддержки SSL.

    Опции CHANGE MASTER TO для других столбцов SSL: MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_CIPHER, MASTER_SSL_CRL, MASTER_SSL_CRLPATH, MASTER_SSL_KEY, MASTER_SSL_VERIFY_SERVER_CERT.

  • CONNECTION_RETRY_INTERVAL

    Число секунд между повторами соединения. (CHANGE MASTER TO опция MASTER_CONNECT_RETRY).

  • CONNECTION_RETRY_COUNT

    Число раз, которое ведомое устройство может попытаться повторно соединиться с ведущим устройством в случае потерянного соединения. (CHANGE MASTER TO опция MASTER_RETRY_COUNT).

  • HEARTBEAT_INTERVAL

    Интервал биения репликации на ведомом устройстве в секундах.

У replication_connection_configuration есть эти индексы:

  • Первичный ключ на (CHANNEL_NAME).

TRUNCATE TABLE не позволен для replication_connection_configuration.

Следующая таблица показывает связь между столбцами replication_connection_configuration и SHOW SLAVE STATUS.

Столбец replication_connection_configuration Столбец SHOW SLAVE STATUS
HOSTMaster_Host
PORTMaster_Port
USERMaster_User
NETWORK_INTERFACEMaster_Bind
AUTO_POSITIONAuto_Position
SSL_ALLOWEDMaster_SSL_Allowed
SSL_CA_FILEMaster_SSL_CA_File
SSL_CA_PATHMaster_SSL_CA_Path
SSL_CERTIFICATE Master_SSL_Cert
SSL_CIPHERMaster_SSL_Cipher
SSL_KEYMaster_SSL_Key
SSL_VERIFY_SERVER_CERTIFICATE Master_SSL_Verify_Server_Cert
SSL_CRL_FILEMaster_SSL_Crl
SSL_CRL_PATH Master_SSL_Crlpath
CONNECTION_RETRY_INTERVAL Connect_Retry
CONNECTION_RETRY_COUNT Master_Retry_Count

23.9.11.2. Таблица replication_connection_status

Эта таблица показывает текущий статус потока ввода/вывода, который обрабатывает ведомое соединение сервера с главным сервером.

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

У replication_connection_status есть эти столбцы:

  • CHANNEL_NAME

    Канал, который эта строка отображает. Всегда есть канал по умолчанию, и больше каналов может быть добавлено. См. раздел 19.2.3.

  • GROUP_NAME

    Этот столбец сохранен для будущего использования.

  • SOURCE_UUID

    server_uuid от ведущего устройства.

  • THREAD_ID

    ID потока I/O.

  • SERVICE_STATE

    ON (поток существует и является активным или спящим), OFF (поток больше не существует) или CONNECTING (поток существует и соединяется с ведущим устройством).

  • RECEIVED_TRANSACTION_SET

    Набор глобальных операционных ID (GTID), соответствующий всем транзакциям, полученным этим ведомым устройством. Пустой, если GTID не используются.

  • LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE

    Код ошибки и сообщение об ошибке, которая заставила поток ввода/вывода останавливаться. Код ошибки 0 и пустая строка не означают отсутствие ошибок. Если LAST_ERROR_MESSAGE не пусто, ошибочные значения также появляются в журнале ошибок ведомого устройства.

    RESET MASTER или RESET SLAVE сбрасывает значения, показанные в этих столбцах.

  • LAST_ERROR_TIMESTAMP

    timestamp в формате YYMMDD HH:MM:SS, который показывает, когда последняя ошибка ввода/вывода имела место.

  • LAST_HEARTBEAT_TIMESTAMP

    timestamp в формате YYMMDD HH:MM:SS, который показывает, когда последний сигнал биения был получен ведомым устройством.

  • COUNT_RECEIVED_HEARTBEATS

    Общее количество сигналов биения, которые ведомое устройство получило с прошлого перезапуска или запроса CHANGE MASTER TO.

У replication_connection_status есть эти индексы:

  • Первичный ключ на (CHANNEL_NAME).

  • Индекс на (THREAD_ID).

TRUNCATE TABLE не позволен для replication_connection_status.

Следующая таблица показывает связь между столбцами replication_connection_status и SHOW SLAVE STATUS.

Столбец replication_connection_status Столбец SHOW SLAVE STATUS
SOURCE_UUIDMaster_UUID
THREAD_IDНет
SERVICE_STATESlave_IO_Running
RECEIVED_TRANSACTION_SET Retrieved_Gtid_Set
LAST_ERROR_NUMBER Last_IO_Errno
LAST_ERROR_MESSAGE Last_IO_Error
LAST_ERROR_TIMESTAMP Last_IO_Error_Timestamp

23.9.11.3. Таблица replication_applier_configuration

Таблица показывает параметры конфигурации, примененные ведомым сервером. Параметры, сохраненные в таблице, могут быть изменены во время выполнения с помощью CHANGE MASTER TO, как обозначено в описаниях столбца.

У replication_applier_configuration есть эти столбцы:

  • CHANNEL_NAME

    Канал, который эта строка отображает. Всегда есть канал по умолчанию, и больше каналов может быть добавлено. См. раздел 19.2.3.

  • DESIRED_DELAY

    Число секунд, которые ведомое устройство должно изолировать ведущее устройство. (CHANGE MASTER TO опция MASTER_DELAY).

У replication_applier_configuration есть эти индексы:

  • Первичный ключ на (CHANNEL_NAME).

TRUNCATE TABLE не позволен для replication_applier_configuration.

Следующая таблица показывает связь между столбцами replication_applier_configuration и SHOW SLAVE STATUS.

Столбец replication_applier_configuration Столбец SHOW SLAVE STATUS
DESIRED_DELAY SQL_Delay

23.9.11.4. Таблица replication_applier_status

Эта таблица показывает текущее общее операционное состояние выполнения на ведомом сервере.

Эта таблица предоставляет информацию об общих аспектах транзакции, которые не являются определенными для любого вовлеченного потока. Определенная для потока информация о статусе доступна в replication_applier_status_by_coordinator replication_applier_status_by_worker, если ведомое устройство является мультипоточным).

У replication_applier_status есть эти столбцы:

  • CHANNEL_NAME

    Канал, который эта строка отображает. Всегда есть канал по умолчанию, и больше каналов может быть добавлено. См. раздел 19.2.3.

  • SERVICE_STATE

    Сохранено для будущего использования.

  • REMAINING_DELAY

    Если ведомое устройство ждет DESIRED_DELAY секунд, так как ведущее устройство применяет случай, это поле содержит оставшееся число секунд задержки. В других случаях это NULL. DESIRED_DELAY сохранено в replication_applier_configuration.

  • COUNT_TRANSACTIONS_RETRIES

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

У replication_applier_status есть эти индексы:

  • Первичный ключ на (CHANNEL_NAME).

TRUNCATE TABLE не позволен для replication_applier_status.

Следующая таблица показывает связь между replication_applier_status и SHOW SLAVE STATUS.

Столбец replication_applier_status Столбец SHOW SLAVE STATUS
SERVICE_STATEНет
REMAINING_DELAY SQL_Remaining_Delay

23.9.11.5. Таблица replication_applier_status_by_coordinator

Для мультипоточного ведомого устройства ведомое устройство использует много рабочих потоков и поток координатора, чтобы управлять ими. Эта таблица показывает состояние потока координатора. Для однопоточного ведомого устройства эта таблица пуста. Для мультипоточного ведомого устройства replication_applier_status_by_worker показывает состояние рабочих потоков.

У replication_applier_status_by_coordinator есть эти столбцы:

  • CHANNEL_NAME

    Канал, который эта строка отображает. Всегда есть канал по умолчанию, и больше каналов может быть добавлено. См. раздел 19.2.3.

  • THREAD_ID

    ID потока SQL/coordinator.

  • SERVICE_STATE

    ON (поток существует и является активным или спящим) или OFF (поток больше не существует).

  • LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE

    Код ошибки и сообщение об ошибке, которая заставила поток SQL/coordinator останавливаться. Код ошибки 0 и пустая строка не означают, что ошибки нет. Если LAST_ERROR_MESSAGE не пусто, ошибочные значения также появляются в журнале ошибок ведомого устройства.

    RESET MASTER или RESET SLAVE сбрасывает значения, показанные в этих столбцах.

    Все коды ошибки и сообщения в LAST_ERROR_NUMBER и LAST_ERROR_MESSAGE соответствуют ошибочным значениям, перечисленным в разделе B.3.

  • LAST_ERROR_TIMESTAMP

    timestamp в формате YYMMDD HH:MM:SS, который показывает, когда последняя ошибка SQL/coordinator произошла.

У replication_applier_status_by_coordinator есть эти индексы:

  • Первичный ключ на (CHANNEL_NAME).

  • Индекс на (THREAD_ID).

TRUNCATE TABLE не позволен для replication_applier_status_by_coordinator.

Следующая таблица показывает связь между replication_applier_status_by_coordinator и SHOW SLAVE STATUS.

Столбец replication_applier_status_by_coordinator Столбец SHOW SLAVE STATUS
THREAD_IDНет
SERVICE_STATE Slave_SQL_Running
LAST_ERROR_NUMBER Last_SQL_Errno
LAST_ERROR_MESSAGE Last_SQL_Error
LAST_ERROR_TIMESTAMP Last_SQL_Error_Timestamp

23.9.11.6. Таблица replication_applier_status_by_worker

Если ведомое устройство не является мультипоточным, эта таблица показывает состояние потока. Иначе, ведомое устройство использует много рабочих потоков и поток координатора, чтобы управлять ими, и эта таблица показывает состояние рабочих потоков. Для мультипоточного ведомого устройства replication_applier_status_by_coordinator показывает состояние потока координатора.

У replication_applier_status_by_worker есть эти столбцы:

  • CHANNEL_NAME

    Канал, который эта строка отображает. Всегда есть канал по умолчанию, и больше каналов может быть добавлено. См. раздел 19.2.3.

  • WORKER_ID

    Идентификатор рабочего (то же самое значение, как столбец id в таблице mysql.slave_worker_info). После STOP SLAVE THREAD_ID становится NULL, но WORKER_ID сохранено.

  • THREAD_ID

    ID рабочего потока.

  • SERVICE_STATE

    ON (поток существует и является активным или спящим) или OFF (поток больше не существует).

  • LAST_SEEN_TRANSACTION

    Транзакция, которую рабочий поток обработал последней. Рабочий поток не обязательно применил эту транзакцию, потому что она могла быть в процессе выполнения.

    Если значение переменной gtid_mode OFF, этот столбец ANONYMOUS, указывая, что транзакции не имеют глобальных операционных идентификаторов (GTID) и идентифицированы только файлом и позицией.

    Если gtid_mode ON, значение столбца определено следующим образом:

    • Если никакая транзакция не выполнена, столбец пуст.

    • Когда транзакция выполнена, столбец установлен как gtid_next. С этого момента столбец всегда показывает GTID.
    • GTID сохранен, пока следующая транзакция не выполнена. Если ошибка происходит, значение столбца GTID транзакции, выполняемой рабочим потоком, когда ошибка произошла.
    • Когда следующий случай журнала GTID поднят этим потоком, этот столбец обновлен из gtid_next вскоре после того, как gtid_next установлен.

  • LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE

    Код ошибки и сообщение об ошибке, которая заставила поток останавливаться. Код ошибки 0 и пустая строка не означают отсутствие ошибки. Если LAST_ERROR_MESSAGE не пусто, ошибочные значения также появляются в журнале ошибок ведомого устройства.

    RESET MASTER или RESET SLAVE сбрасывает значения, показанные в этих столбцах.

    Все коды ошибки и сообщения, выведенные на экран в LAST_ERROR_NUMBER и LAST_ERROR_MESSAGE соответствуют ошибочным значениям, перечисленным в разделе B.3.

  • LAST_ERROR_TIMESTAMP

    timestamp в формате YYMMDD HH:MM:SS, который показывает, когда последняя ошибка рабочего потока произошла.

У replication_applier_status_by_worker есть эти индексы:

  • Первичный ключ на (CHANNEL_NAME, WORKER_ID).

  • Индекс на (THREAD_ID).

TRUNCATE TABLE не позволен для replication_applier_status_by_worker.

Следующая таблица показывает связь между replication_applier_status_by_worker и SHOW SLAVE STATUS.

Столбец replication_applier_status_by_worker Столбец SHOW SLAVE STATUS
WORKER_IDНет
THREAD_IDНет
SERVICE_STATEНет
LAST_SEEN_TRANSACTIONНет
LAST_ERROR_NUMBER Last_SQL_Errno
LAST_ERROR_MESSAGE Last_SQL_Error
LAST_ERROR_TIMESTAMP Last_SQL_Error_Timestamp

23.9.11.7. Таблица replication_group_members

Эта таблица показывает сеть и информацию о статусе для членов группы репликации.

Таблица replication_group_members имеет следующие столбцы:

  • CHANNEL_NAME

    Название группового канала.

  • MEMBER_ID

    Идентификатор для этого участника, то же самое как сервер UUID.

  • MEMBER_HOST

    Сетевой адрес этого участника (имя хоста или IP-адрес).

  • MEMBER_PORT

    Порт, на котором слушает сервер.

  • MEMBER_STATE

    Текущее состояние этого участника, может быть любое из следующего:

    • OFFLINE: Групповой плагин установлен, но не был запущен.

    • RECOVERING: Сервер присоединился к группе, от которой он получает данные.
    • ONLINE: Участник находится в полностью функционирующем статусе.

TRUNCATE TABLE не позволен для replication_group_members.

23.9.11.8. Таблица replication_group_member_stats

Эта таблица показывает статистическую информацию для членов группы.

У replication_group_member_stats есть следующие столбцы:

  • CHANNEL_NAME

    Название группового канала.

  • VIEW_ID

    Идентификатор текущего представления для этой группы.

  • MEMBER_ID

    Идентификатор для этого участника, то же самое как сервер UUID.

  • COUNT_TRANSACTIONS_IN_QUEUE

    Число транзакций в ожидании.

  • COUNT_TRANSACTIONS_CHECKED

    Число транзакций уже удостоверено этим участником.

  • COUNT_CONFLICTS_DETECTED

    Число транзакций, которые не были удостоверены.

  • COUNT_TRANSACTIONS_VALIDATING

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

  • TRANSACTIONS_COMMITTED_ALL_MEMBERS

    Набор устойчивых групповых транзакций.

  • LAST_CONFLICT_FREE_TRANSACTION

    Последняя транзакция, удостоверенная без конфликтов.

TRUNCATE TABLE не позволен для replication_group_member_stats.

23.9.12. Таблицы блокировки Performance Schema

Performance Schema выставляет информацию о блокировке через эти таблицы:

  • data_locks: Блокировки данных.

  • data_lock_waits : Отношения между владельцами блокировок и просителями, заблокированными этими владельцами.
  • metadata_locks : Блокировки метаданных.
  • table_handles: Табличные блокировки.

Следующие разделы описывают эти таблицы более подробно.

23.9.12.1. Таблица data_locks

Таблица data_locks показывает блокировки данных, которые введены и требуются. Для информации о том, какие запросы блокировки заблокированы введеными блокировками, см. раздел 23.9.12.2. Обе таблицы были добавлены в MySQL 8.0.1.

Данные в качестве примера:

mysql> SELECT * FROM data_locks\G
*************************** 1. row ***************************
   ENGINE: INNODB
 ENGINE_LOCK_ID: 4140:74
ENGINE_TRANSACTION_ID: 4140
THREAD_ID: 37
 EVENT_ID: 9
  OBJECT_SCHEMA: test
OBJECT_NAME: t1
 PARTITION_NAME: NULL
SUBPARTITION_NAME: NULL
 INDEX_NAME: NULL
OBJECT_INSTANCE_BEGIN: 140489308280888
LOCK_TYPE: TABLE
LOCK_MODE: IX
LOCK_STATUS: GRANTED
LOCK_DATA: NULL
*************************** 2. row ***************************
   ENGINE: INNODB
 ENGINE_LOCK_ID: 4140:66:5:1
ENGINE_TRANSACTION_ID: 4140
THREAD_ID: 37
 EVENT_ID: 9
  OBJECT_SCHEMA: test
OBJECT_NAME: t1
 PARTITION_NAME: NULL
SUBPARTITION_NAME: NULL
 INDEX_NAME: GEN_CLUST_INDEX
OBJECT_INSTANCE_BEGIN: 140489320307736
LOCK_TYPE: RECORD
LOCK_MODE: X
LOCK_STATUS: GRANTED
LOCK_DATA: supremum pseudo-record

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

Используйте data_locks , чтобы помочь диагностировать исполнительные проблемы, которые происходят во времена тяжелой параллельной загрузки. Для InnoDB см. обсуждение этой темы в разделе 16.14.2 .

У data_locks есть эти столбцы:

  • ENGINE:

    Механизм хранения, который держит или просил блокировку.

  • ENGINE_LOCK_ID:

    ID блокировки. Кортежи зачений (ENGINE_LOCK_ID, ENGINE) уникальны.

    Форматы ID блокировки являются внутренними и подлежат изменению в любое время. Приложения не должны положиться на ID блокировки, имеющие особый формат.

  • ENGINE_TRANSACTION_ID:

    Внутренний ID механизма хранения транзакции, которая просила блокировку.

    Для InnoDB, чтобы получить детали о транзакции, присоединитесь к этому столбцу с TRX_ID из INFORMATION_SCHEMA INNODB_TRX.

  • THREAD_ID:

    ID потока, которому принадлежит блокировка. Чтобы получить детали о потоке, присоединитесь к этому столбцу с THREAD_ID из Performance Schema threads .

  • EVENT_ID:

    Исполнительный случай, который вызвал блокировку. Кортежи (THREAD_ID, EVENT_ID) неявно идентифицируют родительский случай в других таблицах Performance Schema:

    • Родительский случай ожидания в таблице events_waits_xxx.

    • Родительский случай этапа в таблице events_stages_xxx.
    • Родительский случай запроса в таблице events_statements_xxx.
    • Родительский операционный случай в таблице events_transactions_xxx.

    Чтобы получить детали о родительском случае, соедините столбцы THREAD_ID и EVENT_ID со столбцами подобного имени в соответствующей родительской таблице событий.

  • OBJECT_SCHEMA:

    Схема, которая содержит заблокированную таблицу.

  • OBJECT_NAME:

    Название заблокированной таблицы.

  • PARTITION_NAME:

    Название заблокированного разделения, если есть, иначе NULL.

  • SUBPARTITION_NAME:

    Название заблокированного подразделения, если есть, иначе NULL.

  • INDEX_NAME:

    Название заблокированного индекса, если есть, иначе NULL.

    Практически InnoDB всегда создает индекс (GEN_CLUST_INDEX), так что INDEX_NAME не NULL для таблиц InnoDB всегда.

  • OBJECT_INSTANCE_BEGIN:

    Адрес в памяти о блокировке.

  • LOCK_TYPE:

    Тип блокировки.

    Значение зависит от механизма хранения. Для InnoDB разрешенные значения RECORD для блокировки на уровне строки и TABLE для блокировки на уровне таблицы.

  • LOCK_MODE:

    Как блокировку требуют.

    Значение зависит от механизма хранения. Для InnoDB разрешенные значения S[,GAP], X[,GAP], IS[,GAP], IX[,GAP], AUTO_INC и UNKNOWN. Режимы блокировки кроме AUTO_INC и UNKNOWN указывают на блокировки промежутка, если существует. Для информации о S, X, IS, IX и блокировке промежутка, обратитесь к разделу 16.5.1.

  • LOCK_STATUS:

    Состояние запроса блокировки.

    Значение зависит от механизма хранения. Для InnoDB разрешенные значения GRANTED (блокировка проводится) и PENDING (блокировку ждут).

  • LOCK_DATA:

    Данные связанные с блокировкой, если есть.

    Значение зависит от механизма хранения. Для InnoDB это значения первичного ключа заблокированной записи, если LOCK_TYPE RECORD, иначе NULL. Этот столбец содержит значения столбцов первичного ключа в заблокированной строке, отформатированной как допустимая строка SQL (готовая, чтобы быть скопированной в запрос SQL). Если нет никакого первичного ключа, LOCK_DATA уникальный внутренний идентификационный номер строки. InnoDB. Если блокировка промежутка взята для значений ключа или диапазонов выше самого большого значения в индексировании, LOCK_DATA сообщает "supremum pseudo-record". Когда страница, содержащая заблокированную запись, не находится в буферном бассейне (в случае, когда страницы были выгружены на диск в то время, как блокировка проводилась), InnoDB не грузит страницу с диска, чтобы избежать ненужных дисковых операций. Вместо этого LOCK_DATA установлен в NULL.

У data_locks есть эти индексы:

  • Первичный ключ на (ENGINE_LOCK_ID, ENGINE).

  • Индекс на (ENGINE_TRANSACTION_ID, ENGINE).
  • Индекс на (THREAD_ID, EVENT_ID).
  • Индекс на (OBJECT_SCHEMA, OBJECT_NAME, PARTITION_NAME, SUBPARTITION_NAME).

TRUNCATE TABLE не позволен для data_locks .

23.9.12.2. Таблица data_lock_waits

Таблица data_lock_waits осуществляет отношения, показывая, какие данные запирают запросы в data_locks, сдерживая блокировки данных. Сдержанные блокировки в data_locks отобразятся в data_lock_waits только, если они блокируют некоторый запрос блокировки. Обе таблицы были добавлены в MySQL 8.0.1.

Эта информация позволяет Вам понять зависимости от блокировки данных между сеансами. Таблица выставляет не только, которые блокировки держат сеанс, или какую блокировку ждет транзакция, но и то, какая сессия или транзакция в настоящее время проводят ту блокировку.

Блокировка данных в качестве примера:

mysql> SELECT * FROM data_lock_waits\G
*************************** 1. row ***************************
  ENGINE: INNODB
 REQUESTING_ENGINE_LOCK_ID: 4141:66:5:2
REQUESTING_ENGINE_TRANSACTION_ID: 4141
REQUESTING_THREAD_ID: 38
 REQUESTING_EVENT_ID: 11
REQUESTING_OBJECT_INSTANCE_BEGIN: 140489320441368
   BLOCKING_ENGINE_LOCK_ID: 4140:66:5:2
  BLOCKING_ENGINE_TRANSACTION_ID: 4140
  BLOCKING_THREAD_ID: 37
   BLOCKING_EVENT_ID: 9
  BLOCKING_OBJECT_INSTANCE_BEGIN: 140489320307736

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

Используйте data_locks , чтобы помочь диагностировать исполнительные проблемы, которые происходят во времена тяжелой параллельной загрузки. Для InnoDB см. обсуждение этой темы в разделе 16.14.2 .

Поскольку столбцы в data_lock_waits подобны столбцам в data_locks, описания столбцов здесь сокращены. Для более подробных описаний столбцов см. раздел 23.9.12.1.

У data_lock_waits есть эти столбцы:

  • ENGINE

    Механизм хранения, который запросил блокировку.

  • REQUESTING_ENGINE_LOCK_ID

    ID блокировки, которую требует механизм хранения. Чтобы получить детали о блокировке, присоедините к этому столбцу LOCK_ID из data_locks.

  • REQUESTING_ENGINE_TRANSACTION_ID

    Внутренний ID механизма хранения транзакции, который запросил блокировку.

  • REQUESTING_THREAD_ID

    ID потока сеанса, который запросил блокировку.

  • REQUESTING_EVENT_ID

    Случай Performance Schema, который вызвал запрос блокировки в сеансе, который запросил блокировку.

  • REQUESTING_OBJECT_INSTANCE_BEGIN

    Адрес в памяти о требуемой блокировке.

  • BLOCKING_ENGINE_LOCK_ID

    ID блокировки. Чтобы получить детали о блокировке, присоединитесь к этому столбцу с LOCK_ID из data_locks.

  • BLOCKING_ENGINE_TRANSACTION_ID

    Внутренний ID механизма хранения транзакции, которая держит блокировку.

  • BLOCKING_THREAD_ID

    ID потока сеанса, который держит блокировку.

  • BLOCKING_EVENT_ID

    Случай Performance Schema, который вызвал блокировку в сеансе.

  • BLOCKING_OBJECT_INSTANCE_BEGIN

    Адрес в памяти о блокировке.

У data_lock_waits есть эти индексы:

  • Индекс на (REQUESTING_ENGINE_LOCK_ID, ENGINE).

  • Индекс на (BLOCKING_ENGINE_LOCK_ID, ENGINE).
  • Индекс на (REQUESTING_ENGINE_TRANSACTION_ID, ENGINE).
  • Индекс на (BLOCKING_ENGINE_TRANSACTION_ID, ENGINE).
  • Индекс на (REQUESTING_THREAD_ID, REQUESTING_EVENT_ID).
  • Индекс на (BLOCKING_THREAD_ID, BLOCKING_EVENT_ID).

TRUNCATE TABLE не позволен для data_lock_waits .

23.9.12.3. Таблица metadata_locks

Performance Schema выставляет информацию о блокировке метаданных через metadata_locks:

  • Блокировки, которые предоставили.

  • Блокировки, которые требовали, но еще не предоставили.
  • Запросы блокировки, которые были уничтожены датчиком тупика или рассчитаны и ждут блокировки.

Эта информация позволяет Вам понять зависимости от блокировки метаданных между сеансами. Вы можете видеть не только, которые блокировки сеанс ждет, но и какая сессия в настоящее время проводит эту блокировку.

metadata_locks только для чтения и не может быть обновлена. Это задано по умолчанию, чтобы сконфигурировать табличный размер, установите системную переменную performance_schema_max_metadata_locks при запуске сервера.

Инструментовка блокировки метаданных отключена по умолчанию. Чтобы включить, запустите инструмент wait/lock/metadata/sql/mdl в setup_instruments .

Performance Schema поддерживает табличный контент metadata_locks следующим образом, используя столбец LOCK_STATUS, чтобы указать на состояние каждой блокировки:

  • Когда блокировку метаданных требуют и немедленно получают, строка с состоянием GRANTED вставлена.

  • Когда блокировку метаданных требуют и немедленно не получают, строка с состоянием PENDING вставлена.
  • Когда блокировку метаданных, которую ранее требуют, предоставляют, состояние ее строки обновлено к GRANTED.
  • Когда блокировка метаданных выпущена, ее строка удалена.
  • Когда запрос блокировки на ожидании отменен датчиком тупика, чтобы сломать тупик ( ER_LOCK_DEADLOCK), состояние строки обновлено от PENDING до VICTIM.
  • Когда запрос блокировки получает тайм-аут (ER_LOCK_WAIT_TIMEOUT ), состояние строки обновлено от PENDING до TIMEOUT.
  • Когда предоставленная блокировка или запрос блокировки на ожидании уничтожен, состояние строки обновлено от GRANTED или PENDING до KILLED.
  • Статусы VICTIM, TIMEOUT и KILLED кратки и показывают, что строка блокировки собирается быть удаленной.
  • Статусы PRE_ACQUIRE_NOTIFY и POST_RELEASE_NOTIFY кратки и показывают, что подсистема блокировки метаданных регистрирует заинтересованные механизмы хранения, вводя приобретение блокировки или оставляя операции выпуска блокировки.

У metadata_locks есть эти столбцы:

  • OBJECT_TYPE

    Тип блокировки, использованный в подсистеме блокировки метаданных, значение одно из GLOBAL, SCHEMA, TABLE, FUNCTION, PROCEDURE, TRIGGER (сейчас не используется), EVENT, COMMIT, USER LEVEL LOCK, TABLESPACE или LOCKING SERVICE.

    Значение USER LEVEL LOCK указывает на блокировку, приобретенную с GET_LOCK() . Значение LOCKING SERVICE указывает, что блокировка приобреталась с использованием службы блокировки, описанной в разделе 26.3.1.

  • OBJECT_SCHEMA

    Схема, которая содержит объект.

  • OBJECT_NAME

    Название инструментованного объекта.

  • OBJECT_INSTANCE_BEGIN

    Адрес в памяти об инструментованном объекте.

  • LOCK_TYPE

    Тип блокировки от подсистемы метаданных блокировок. Значение одно из INTENTION_EXCLUSIVE, SHARED, SHARED_HIGH_PRIO, SHARED_READ, SHARED_WRITE, SHARED_UPGRADABLE, SHARED_NO_WRITE, SHARED_NO_READ_WRITE или EXCLUSIVE.

  • LOCK_DURATION

    Продолжительность блокировки от подсистемы метаданных блокировок. Значение одно из STATEMENT, TRANSACTION или EXPLICIT. STATEMENT и TRANSACTION для блокировок, которые выпущены в запросе или операционном конце, соответственно. EXPLICIT значение для блокировок, которые переживают запрос или конец транзакции и выпущены явно, такие как глобальные блокировки, приобретенные с FLUSH TABLES WITH READ LOCK.

  • LOCK_STATUS

    Состояние блокировки от подсистемы метаданных блокировок. Значение одно из PENDING, GRANTED, VICTIM, TIMEOUT, KILLED, PRE_ACQUIRE_NOTIFY или POST_RELEASE_NOTIFY. Performance Schema назначает эти значения как описано ранее в этом разделе.

  • SOURCE

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

  • OWNER_THREAD_ID

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

  • OWNER_EVENT_ID

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

У metadata_locks есть эти индексы:

  • Первичный ключ на (OBJECT_INSTANCE_BEGIN).

  • Индекс на (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME).
  • Индекс на (OWNER_THREAD_ID, OWNER_EVENT_ID).

TRUNCATE TABLE не позволен для metadata_locks .

23.9.12.4. Таблица table_handles

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

table_handles только для чтения и не может быть обновлена. Это задано по умолчанию, чтобы сконфигурировать табличный размер, установите переменную performance_schema_max_table_handles при запуске сервера.

У table_handles есть эти столбцы:

  • OBJECT_TYPE

    Таблица открылась табличным дескриптором.

  • OBJECT_SCHEMA

    Схема, которая содержит объект.

  • OBJECT_NAME

    Название инструментованного объекта.

  • OBJECT_INSTANCE_BEGIN

    Табличный дескриптор в памяти.

  • OWNER_THREAD_ID

    Поток, имеющий табличный дескриптор.

  • OWNER_EVENT_ID

    Случай, который заставил табличный дескриптор быть открытым.

  • INTERNAL_LOCK

    Табличная блокировка на уровне SQL. Значение одно из READ, READ WITH SHARED LOCKS, READ HIGH PRIORITY, READ NO INSERT, WRITE ALLOW WRITE, WRITE CONCURRENT INSERT, WRITE LOW PRIORITY или WRITE. Для информации об этих типах блокировки см. файл исходных текстов include/thr_lock.h.

  • EXTERNAL_LOCK

    Табличная блокировка на уровне механизма хранения. Значение одно из READ EXTERNAL или WRITE EXTERNAL.

У table_handles есть эти индексы:

  • Первичный ключ на (OBJECT_INSTANCE_BEGIN).

  • Индекс на (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME).
  • Индекс на (OWNER_THREAD_ID, OWNER_EVENT_ID).

TRUNCATE TABLE не позволен для table_handles .

23.9.13. Системные таблицы переменных Performance Schema

Значение переменной show_compatibility_56 затрагивает информацию, доступную из таблиц global_variables, session_variables и variables_by_thread, описанных здесь (variables_info не затронута). Для деталей см. описание той переменной в разделе 6.1.5.

MySQL server поддерживает много системных переменных, которые указывают, как он сконфигурирован (см. раздел 6.1.5). Системная информация о переменных доступна в этих таблицах Performance Schema:

  • global_variables: Глобальные системные переменные. Приложение, которое хочет только глобальные значения, должно использовать эту таблицу.

  • session_variables: Системные переменные для текущего сеанса. Приложение, которое хочет все системные значения переменной для собственного сеанса, должно использовать эту таблицу. Это включает переменные сеанса для своего сеанса, так же как значения глобальных переменных, у которых нет никакой сеансовой копии.
  • variables_by_thread: Системные переменные сеанса для каждого активного сеанса. Приложение, которое хочет знать значения переменной сеанса для определенных сеансов, должно использовать эту таблицу. Это включает только переменные сеанса, идентифицированные ID потока.
  • variables_info: Показывает для каждой системной переменной источник, из которого это было последний раз установлено, и диапазон значений. См. раздел 23.9.13.1.

Таблицы переменной сеанса ( session_variables, variables_by_thread) содержат информацию только для активных сеансов, не законченных сеансов.

TRUNCATE TABLE не допускается для системных таблиц переменных Performance Schema.

У global_variables и session_variables есть эти столбцы:

  • VARIABLE_NAME

    Системное имя переменной.

  • VARIABLE_VALUE

    Системное значение переменной. Для global_variables этот столбец содержит глобальное значение. Для session_variables этот столбец содержит значение переменной для текущего сеанса.

У global_variables и session_variables есть индексы:

  • Первичный ключ на (VARIABLE_NAME).

У variables_by_thread есть эти столбцы:

  • THREAD_ID

    Идентификатор потока сеанса, в котором определена системная переменная.

  • VARIABLE_NAME

    Системное имя переменной.

  • VARIABLE_VALUE

    Значение переменной сеанса для сеанса, названного в столбце THREAD_ID.

У variables_by_thread есть эти индексы:

  • Первичный ключ на (THREAD_ID, VARIABLE_NAME).

variables_by_thread содержит системную информацию о переменных только о потоках переднего плана. Если не все потоки будут инструментованы Performance Schema, эта таблица пропустит некоторые строки. В этом случае переменная состояния Performance_schema_thread_instances_lost будет больше, чем ноль.

23.9.13.1. Таблица variables_info

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

У variables_info есть эти столбцы:

  • VARIABLE_NAME

    Имя переменной.

  • VARIABLE_SOURCE

    Источник, из которого была последний раз установлена переменная:

    • COMMAND_LINE

      Переменная была установлена из командной строки.

    • COMPILED

      У переменной есть значение по умолчанию. COMPILED это значение, используемое для переменных, не заданных любым другим путем.

    • DYNAMIC

      Переменная была установлена во время выполнения. Это включает задание переменных в пределах файлов, определенных, используя опцию --init-file.

    • EXPLICIT

      Переменная была установлена из файла опции, названного в опции --defaults-file .

    • EXTRA

      Переменная была установлена из файла опции, названного в опции --defaults-extra-file.

    • GLOBAL

      Переменная была установлена из глобального файла опции. Это включает файлы опции, не покрытые EXPLICIT, EXTRA, LOGIN, PERSISTED, SERVER или USER.

    • LOGIN

      Переменная была установлена из определенного для пользователя файла входа в систему (~/.mylogin.cnf).

    • PERSISTED

      Переменная была установлена из определенного для сервера файла опций mysqld-auto.cnf. Ни у какой строки нет этого значения, если сервер был запущен с выключенной persisted_globals_load.

    • SERVER

      Переменная была установлена из определенного для сервера файла опций $MYSQL_HOME/my.cnf. Для деталей см. раздел 5.2.6.

    • USER

      Переменная была установлена из определенного для пользователя файла опций ~/.my.cnf.

  • VARIABLE_PATH

    Если переменная была установлена из файла опции, VARIABLE_PATH путь к этому файлу. Иначе значение пустая строка.

  • MIN_VALUE, MAX_VALUE

    Минимальные и максимальные разрешенные значения для переменной. Оба 0 для переменных, у которых нет таких значений (то есть, переменные, которые не являются числовыми).

TRUNCATE TABLE не позволен для variables_info .

Если переменная с VARIABLE_SOURCE, кроме DYNAMIC установлена во время выполнения, VARIABLE_SOURCE становится DYNAMIC, а VARIABLE_PATH пустой строкой.

Системная переменная, у которой есть только значение сеанса (такая как debug_sync) не может быть установлена при запуске. Для системных переменных только для сеанса VARIABLE_SOURCE может быть только COMPILED или DYNAMIC.

Если у системной переменной есть неожиданное VARIABLE_SOURCE, рассмотрите свой метод запуска сервера. Например, mysqld_safe читает файлы опции и передает определенные опции, которые он находит там как часть командной строки, которую он использует, чтобы запустить mysqld. Следовательно, некоторые системные переменные, которые Вы устанавливаете в файлах опции, могли бы отобразиться в variables_info как COMMAND_LINE вместо GLOBAL или SERVER.

Некоторые типовые запросы, которые используют variables_info:

  • Показать переменные из командной строки:

    mysql> SELECT VARIABLE_NAME FROM variables_info
                     WHERE VARIABLE_SOURCE = 'COMMAND_LINE'
                     ORDER BY VARIABLE_NAME;
    +---------------+
    | VARIABLE_NAME |
    +---------------+
    | basedir       |
    | datadir       |
    | log_error     |
    | pid_file      |
    | plugin_dir    |
    | port          |
    +---------------+
    
  • Показать переменные из постоянного хранения:
    mysql> SELECT VARIABLE_NAME FROM variables_info
                     WHERE VARIABLE_SOURCE = 'PERSISTED'
                     ORDER BY VARIABLE_NAME;
    +--------------------------+
    | VARIABLE_NAME            |
    +--------------------------+
    | event_scheduler          |
    | expire_logs_days         |
    | max_connections          |
    | validate_password_policy |
    +--------------------------+
    
  • Соединение variables_info с global_variables, чтобы вывести на экран текущие значения сохраненных переменных, вместе с их диапазоном значений:
    mysql> SELECT VI.VARIABLE_NAME, GV.VARIABLE_VALUE,
                     VI.MIN_VALUE,VI.MAX_VALUE FROM variables_info AS VI
                     INNER JOIN global_variables AS GV USING(VARIABLE_NAME)
                     WHERE VI.VARIABLE_SOURCE = 'PERSISTED'
                     ORDER BY VARIABLE_NAME;
    +--------------------------+----------------+-----------+-----------+
    | VARIABLE_NAME            | VARIABLE_VALUE | MIN_VALUE | MAX_VALUE |
    +--------------------------+----------------+-----------+-----------+
    | event_scheduler          | ON             | 0         | 0         |
    | expire_logs_days         | 7              | 0         | 99        |
    | max_connections          | 200            | 1         | 100000    |
    | validate_password_policy | STRONG         | 0         | 0         |
    +--------------------------+----------------+-----------+-----------+
    

23.9.14. Таблицы состояния переменных Performance Schema

Значение переменной show_compatibility_56 затрагивает информацию, доступную из таблиц, описанных здесь. Для деталей см. описание этой переменной в разделе 6.1.5.

Сервер MySQL поддерживает много переменных состояния, которые предоставляют информацию о его работе (см. раздел 6.1.7). Информация о переменной состояния доступна в этих таблицах Performance Schema:

  • global_status: Глобальные переменные состояния. Приложение, которое хочет только глобальные значения, должно использовать эту таблицу.

  • session_status: Переменные состояния для текущего сеанса. Приложение, которое хочет все значения переменной состояния для собственного сеанса, должно использовать эту таблицу. Это включает переменные сеанса для своего сеанса, так же как значения глобальных переменных, у которых нет никакой сеансовой копии.
  • status_by_thread: Переменные состояния сеанса для каждого активного сеанса. Приложение, которое хочет знать значения переменной сеанса для определенных сеансов, должно использовать эту таблицу. Это включает только переменные сеанса, идентифицированные ID потока.

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

Таблицы переменной сеанса ( session_status, status_by_thread) содержат информацию только для активных, а не законченных сеансов.

Performance Schema собирает статистические данные для глобальных переменных состояния только для потоков для которых значение INSTRUMENTED YES в threads. Статистические данные для переменных состояния сеанса всегда собираются, независимо от значения INSTRUMENTED.

Performance Schema не собирает статистические данные для переменных состояния Com_xxx в таблицах переменных состояния. Чтобы получить глобальное и сессионное количество выполнения запросов за сеанс, используйте events_statements_summary_global_by_event_name и events_statements_summary_by_thread_by_event_name , соответственно. Например:

SELECT EVENT_NAME, COUNT_STAR
       FROM events_statements_summary_global_by_event_name
       WHERE EVENT_NAME LIKE 'statement/sql/%';

У global_status и session_status есть эти столбцы:

  • VARIABLE_NAME

    Имя переменной состояния.

  • VARIABLE_VALUE

    Значение переменной состояния. Для global_status этот столбец содержит глобальное значение. Для session_status этот столбец содержит значение для текущего сеанса.

У global_status и session_status есть индексы:

  • Первичный ключ на (VARIABLE_NAME).

status_by_thread содержит состояние каждого активного потока. У нее есть эти столбцы:

  • THREAD_ID

    Идентификатор потока сеанса, в котором определена переменная состояния.

  • VARIABLE_NAME

    Имя переменной состояния.

  • VARIABLE_VALUE

    Значение переменной сеанса для сеанса, названного в столбце THREAD_ID.

У status_by_thread есть эти индексы:

  • Первичный ключ на (THREAD_ID, VARIABLE_NAME).

status_by_thread содержит информацию о переменной состояния только о потоках переднего плана. Если переменная performance_schema_max_thread_instances не автомасштабируется (установлена в -1), и максимальное разрешенное число инструментованных объектов потока не больше, чем число фоновых потоков, таблица будет пуста.

Performance Schema поддерживает TRUNCATE TABLE для таблиц переменных состояния следующим образом:

  • global_status: Сбрасывает потоки, учетные записи, узлы и пользователей. Сбрасывает глобальные переменные состояния кроме тех, которые никогда не сбрасывает сервер.

  • session_status: Не поддерживается.
  • status_by_thread: Состояние совокупностей для всех потоков к глобальному состоянию и состоянию учетной записи, затем сбрасывает состояние потока. Если статистические данные учетной записи не собраны, состояние сеанса добавлено к состояниям хоста и пользователя, если они собраны.

    Учетная запись, узел и пользовательская статистика не собраны, если переменные performance_schema_accounts_size, performance_schema_hosts_size и performance_schema_users_size, соответственно, установлены в 0.

FLUSH STATUS добавляет состояние сеанса из всех активных сеансов в глобальные переменные состояния, сбрасывает состояние всех активных сеансов и сбрасывает значения состояния учетной записи, узла и пользователя от разъединенных сеансов.

23.9.15. Сводные таблицы Performance Schema

Сводные таблицы предоставляют соединенную информацию для законченных событий в течение долгого времени. Таблицы в этой группе суммируют данные событий по-разному.

Резюме событий ожидания:

Резюме этапа:

Резюме запросов:

Операционные резюме:

Резюме ожидания объекта:

Резюме ввода/вывода файла:

Табличный ввод / вывод и ожидание блокировки:

Резюме сокета:

Резюме памяти:

Резюме ошибок:

Резюме переменных состояния:

  • status_by_account: Переменные состояния, связанные с учетной записью.

  • status_by_host: Переменные состояния, связанные с именем хоста.
  • status_by_user: Переменные состояния, связанные с именем пользователя.

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

Сводные таблицы могут быть усечены с TRUNCATE TABLE. Вообще, эффект состоит в том, чтобы сбросить сводные столбцы к 0 или NULL, а не удалить строки. Это позволяет очистить собранные значения. Это могло бы быть полезно, например, после того, как Вы произвели изменение конфигурации во время выполнения. Исключения к этому поведению усечения отмечены в отдельных разделах сводной таблицы.

23.9.15.1. Сводные таблицы событий ожидания

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

Пример информации о резюме событий:

mysql> SELECT * FROM events_waits_summary_global_by_event_name\G
...
*************************** 6. row ***************************
EVENT_NAME: wait/synch/mutex/sql/BINARY_LOG::LOCK_index
COUNT_STAR: 8
SUM_TIMER_WAIT: 2119302
MIN_TIMER_WAIT: 196092
AVG_TIMER_WAIT: 264912
MAX_TIMER_WAIT: 569421
...
*************************** 9. row ***************************
EVENT_NAME: wait/synch/mutex/sql/hash_filo::lock
COUNT_STAR: 69
SUM_TIMER_WAIT: 16848828
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 244185
MAX_TIMER_WAIT: 735345
...

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

  • events_waits_summary_by_account_by_event_name имеет столбцы EVENT_NAME, USER и HOST. Каждая строка суммирует события для сделанного отчета (комбинация пользователя и узла) и имя событий.

  • events_waits_summary_by_host_by_event_name имеет столбцы EVENT_NAME и HOST. Каждая строка суммирует события для данного узла и имени событий.
  • events_waits_summary_by_instance имеет столбцы EVENT_NAME и OBJECT_INSTANCE_BEGIN. Каждая строка суммирует события для данного имени событий и объекта. Если инструмент используется, чтобы создать многократные случаи, у каждого случая есть уникальное значение OBJECT_INSTANCE_BEGIN и он получен в итоге отдельно в этой таблице.
  • events_waits_summary_by_thread_by_event_name имеет столбцы THREAD_ID и EVENT_NAME. Каждая строка суммирует события для данного потока и имени событий.
  • events_waits_summary_by_user_by_event_name имеет столбцы EVENT_NAME и USER. Каждая строка суммирует события для данного пользователя и имени событий.
  • events_waits_summary_global_by_event_name имеет столбец EVENT_NAME. Каждая строка суммирует события для данного имени событий. Инструмент мог бы использоваться, чтобы создать многократные случаи инструментованного объекта. Например, если есть инструмент для mutex, который создается для каждого соединения, есть так много случаев, сколько есть соединений. Сводная строка для инструмента подводит итог по всем этим случаям.

У сводной таблицы событий есть эти сводные столбцы, содержащие соединенные значения:

  • COUNT_STAR

    Число полученных в итоге событий. Это значение включает все события.

  • SUM_TIMER_WAIT

    Общее количество времени ожидания полученных в итоге рассчитанных событий. Это значение вычислено только для рассчитанных событий, потому что у нерассчитанных событий время ожидания NULL. The То же самое истина для других значений xxx_TIMER_WAIT.

  • MIN_TIMER_WAIT

    Минимум времени ожидания полученных в итоге рассчитанных событий.

  • AVG_TIMER_WAIT

    Среднее время ожидания полученных в итоге рассчитанных событий.

  • MAX_TIMER_WAIT

    Максимум времени ожидания полученных в итоге рассчитанных событий.

Сводные таблицы событий имеют индексы:

TRUNCATE TABLE позволен на сводных таблицах. Это имеет эффекты:

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

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

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

23.9.15.2. Сводные таблицы этапа

Performance Schema поддерживает таблицы для того, чтобы собрать текущие и недавние события этапа. Раздел 23.9.5 описывает события, на которых базируются резюме этапа.

Информация о резюме этапа событий в качестве примера:

mysql> SELECT * FROM events_stages_summary_global_by_event_name\G
...
*************************** 5. row ***************************
EVENT_NAME: stage/sql/checking permissions
COUNT_STAR: 57
SUM_TIMER_WAIT: 26501888880
MIN_TIMER_WAIT: 7317456
AVG_TIMER_WAIT: 464945295
MAX_TIMER_WAIT: 12858936792
...
*************************** 9. row ***************************
EVENT_NAME: stage/sql/closing tables
COUNT_STAR: 37
SUM_TIMER_WAIT: 662606568
MIN_TIMER_WAIT: 1593864
AVG_TIMER_WAIT: 17907891
MAX_TIMER_WAIT: 437977248
...

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

  • events_stages_summary_by_account_by_event_name имеет столбцы EVENT_NAME, USER и HOST. Каждая строка суммирует события для сделанного отчета (комбинация пользователя и узла) и имени события.

  • events_stages_summary_by_host_by_event_name имеет столбцы EVENT_NAME и HOST. Каждая строка суммирует события для данного узла и имени событий.
  • events_stages_summary_by_thread_by_event_name имеет столбцы THREAD_ID и EVENT_NAME. Каждая строка суммирует события для данного потока и имени событий.
  • events_stages_summary_by_user_by_event_name имеет столбцы EVENT_NAME и USER. Каждая строка суммирует события для данного пользователя и имени событий.
  • events_stages_summary_global_by_event_name имеет столбец EVENT_NAME. Каждая строка суммирует события для данного имени события.

У каждой сводной таблицы этапа есть эти сводные столбцы, содержащие соединенные значения: COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT и MAX_TIMER_WAIT. Эти столбцы походят на столбцы с теми же именами в сводных таблицах событий ожидания (см. раздел 23.9.15.1), за исключением того, что события совокупности сводных таблиц этапа из events_stages_current вместо events_waits_current .

Сводные таблицы этапа имеют индексы:

TRUNCATE TABLE позволен на сводных таблицах этапа. Это имеет эффекты:

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

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

Кроме того, каждая сводная таблица этапа, которая соединена с учетной записью, узлом, пользователем или потоком, является неявно усеченной усечением таблицы, от которой это зависит, или усечением events_stages_summary_global_by_event_name.

23.9.15.3. Сводные таблицы запросов

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

Информация о резюме запросов событий в качестве примера:

mysql> SELECT * FROM events_statements_summary_global_by_event_name\G
*************************** 1. row ***************************
 EVENT_NAME: statement/sql/select
 COUNT_STAR: 25
 SUM_TIMER_WAIT: 1535983999000
 MIN_TIMER_WAIT: 209823000
 AVG_TIMER_WAIT: 61439359000
 MAX_TIMER_WAIT: 1363397650000
  SUM_LOCK_TIME: 20186000000
 SUM_ERRORS: 0
   SUM_WARNINGS: 0
SUM_ROWS_AFFECTED: 0
  SUM_ROWS_SENT: 388
SUM_ROWS_EXAMINED: 370
SUM_CREATED_TMP_DISK_TABLES: 0
 SUM_CREATED_TMP_TABLES: 0
 SUM_SELECT_FULL_JOIN: 0
 SUM_SELECT_FULL_RANGE_JOIN: 0
 SUM_SELECT_RANGE: 0
 SUM_SELECT_RANGE_CHECK: 0
SUM_SELECT_SCAN: 6
SUM_SORT_MERGE_PASSES: 0
 SUM_SORT_RANGE: 0
  SUM_SORT_ROWS: 0
  SUM_SORT_SCAN: 0
SUM_NO_INDEX_USED: 6
 SUM_NO_GOOD_INDEX_USED: 0
...

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

  • events_statements_summary_by_account_by_event_name имеет столбцы EVENT_NAME, USER и HOST. Каждая строка суммирует события для сделанного отчета (комбинация пользователя и узла) и имя событий.

  • events_statements_summary_by_digest имеет столбцы SCHEMA_NAME и DIGEST. Каждая строка суммирует события для данных значений схемы/обзора. DIGEST_TEXT содержит соответствующий нормализованный текст обзора запроса, но не является ни группировкой, ни сводным столбцом.

    Максимальное количество строк в таблице задано при запуске сервера. Чтобы установить этот максимум явно, установите системнуюая переменную performance_schema_digests_size при запуске сервера.

  • events_statements_summary_by_host_by_event_name имеет столбцы EVENT_NAME и HOST. Каждая строка суммирует события для данного узла и имени событий.
  • events_statements_summary_by_program имеет столбцы OBJECT_TYPE, OBJECT_SCHEMA и OBJECT_NAME. Каждая строка суммирует события для данной сохраненной программы (хранимая процедура или функция, триггер или событие).
  • events_statements_summary_by_thread_by_event_name имеет столбцы THREAD_ID и EVENT_NAME. Каждая строка суммирует события для данного потока и имени событий.
  • events_statements_summary_by_user_by_event_name имеет столбцы EVENT_NAME и USER. Каждая строка суммирует события для данного пользователя и имени событий.
  • events_statements_summary_global_by_event_name имеет столбец EVENT_NAME. Каждая строка суммирует события для данного имени события.
  • prepared_statements_instances имеет столбец OBJECT_INSTANCE_BEGIN. Каждая строка суммирует события для данного подготовленного запроса.

У каждой сводной таблицы запросов есть эти сводные столбцы, содержащие соединенные значения (с исключениями, как отмечено):

  • COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

    Эти столбцы походят на столбцы с теми же самыми именами в сводных таблицах событий (см. раздел 23.9.15.1), за исключением того, что события сводных таблиц запросов собраны из events_statements_current вместо events_waits_current .

    У prepared_statements_instances нет этих столбцов.

  • SUM_xxx

    Совокупность соответствующих столбцов xxx в events_statements_current. Например, столбцы SUM_LOCK_TIME и SUM_ERRORS в сводных таблицах запросов это совокупности столбцов LOCK_TIME и ERRORS в events_statements_current.

У events_statements_summary_by_digest есть эти дополнительные сводные столбцы:

  • FIRST_SEEN_TIMESTAMP, LAST_SEEN_TIMESTAMP

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

У events_statements_summary_by_program есть эти дополнительные сводные столбцы:

  • COUNT_STATEMENTS, SUM_STATEMENTS_WAIT, MIN_STATEMENTS_WAIT, AVG_STATEMENTS_WAIT, MAX_STATEMENTS_WAIT

    Статистика о вложенных запросах во время выполнения сохраненной программы.

У prepared_statements_instances есть эти дополнительные сводные столбцы:

  • COUNT_EXECUTE, SUM_TIMER_EXECUTE, MIN_TIMER_EXECUTE, AVG_TIMER_EXECUTE, MAX_TIMER_EXECUTE

    Соединенная статистика для выполнения готового запроса.

Сводные таблицы запросы имеют индексы:

TRUNCATE TABLE позволен для сводных таблиц запросов. Это имеет эффекты:

  • Для events_statements_summary_by_digest это удаляет строки.

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

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

Правила агрегации обзоров запросов

Если потребитель включен statement_digest, агрегация в events_statements_summary_by_digest происходит следующим образом, когда запрос завершается. Агрегация основана на значении DIGEST, вычисленном для запроса.

  • Если строка events_statements_summary_by_digest уже существует со значением обзора для запроса, который только что завершился, статистические данные для запроса присоединены к этой строке. Столбец LAST_SEEN обновлен к текущему времени.

  • Если ни у какой строки нет значения обзора для запроса, который только что завершился, и таблица не полна, новая строка создается для запроса. FIRST_SEEN и LAST_SEEN инициализированы с текущим временем.
  • Если ни у какой строки нет значения обзора для запроса, который только что завершился, и таблица полна, статистические данные для запроса добавлены к специальной строке catch-all с DIGEST = NULL, который создается в случае необходимости. Если строка создается, столбцы FIRST_SEEN и LAST_SEEN инициализированы с текущим временем. Иначе LAST_SEEN обновлен с текущим временем.

Строка с DIGEST = NULL поддержана, потому что у таблиц Performance Schema есть максимальный размер из-за ограничений памяти. Строка DIGEST = NULL разрешает обзоры, которые не соответствуют другим строкам, которые будут посчитаны, даже если сводная таблица полна. Эта строка помогает Вам оценить, является ли резюме обзора представительным:

  • Строка DIGEST = NULL, у которой есть значение COUNT_STAR, которое представляет 5% всех обзоров, показывает, что сводная таблица обзора является очень представительной: другие строки покрывают 95% замеченных запросов.

  • Строка DIGEST = NULL, у которой есть значение COUNT_STAR, которое представляет 50% всех обзоров, показывает, что сводная таблица обзора не является очень представительной: другие строки покрывают только половину замеченных запросов. Наиболее вероятно DBA должен увеличить максимальный табличный размер так, чтобы больше строк включилось, а строка DIGEST = NULL была бы посчитана, используя более определенные строки вместо этого. Чтобы сделать это, установите системную переменную performance_schema_digests_size к большему значению при запуске сервера. Размер значения по умолчанию 200.

Поведение инструментовки сохраненной программы

Для типов сохраненных программ, для которых инструментовка включена в setup_objects, events_statements_summary_by_program поддерживает статистику для сохраненных программ следующим образом:

  • Строка добавлена для объекта, когда он сначала используется в сервере.

  • Строка для объекта удалена, когда объект удален.
  • Статистические данные соединены в строке для объекта, как он выполняется.

23.9.15.4. Операционные сводные таблицы

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

Операционная информация о резюме событий в качестве примера:

mysql> SELECT * FROM events_transactions_summary_global_by_event_name
                   LIMIT 1\G
*************************** 1. row ***************************
EVENT_NAME: transaction
COUNT_STAR: 5
SUM_TIMER_WAIT: 19550092000
MIN_TIMER_WAIT: 2954148000
AVG_TIMER_WAIT: 3910018000
MAX_TIMER_WAIT: 5486275000
COUNT_READ_WRITE: 5
SUM_TIMER_READ_WRITE: 19550092000
MIN_TIMER_READ_WRITE: 2954148000
AVG_TIMER_READ_WRITE: 3910018000
MAX_TIMER_READ_WRITE: 5486275000
 COUNT_READ_ONLY: 0
 SUM_TIMER_READ_ONLY: 0
 MIN_TIMER_READ_ONLY: 0
 AVG_TIMER_READ_ONLY: 0
 MAX_TIMER_READ_ONLY: 0

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

У каждой операционной сводной таблицы есть эти сводные столбцы, содержащие соединенные значения:

  • COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

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

  • COUNT_READ_WRITE, SUM_TIMER_READ_WRITE, MIN_TIMER_READ_WRITE, AVG_TIMER_READ_WRITE, MAX_TIMER_READ_WRITE

    Они подобны COUNT_STAR и xxx_TIMER_WAIT, но подводят итог только транзакций чтения-записи.

  • COUNT_READ_ONLY, SUM_TIMER_READ_ONLY, MIN_TIMER_READ_ONLY, AVG_TIMER_READ_ONLY, MAX_TIMER_READ_ONLY

    Они подобны COUNT_STAR и xxx_TIMER_WAIT, но подводят итог только транзакций чтения.

Операционные сводные таблицы имеют индексы:

TRUNCATE TABLE позволен для операционных сводных таблиц. Это имеет эффекты:

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

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

Правила агрегирования транзакций

Операционный сбор событий происходит без отношения с уровнем изоляции, режимом доступа или режимом autocommit.

Транзакции чтения-записи вообще требуют больше ресурсов, чем транзакции только для чтения, поэтому операционные сводные таблицы включают отдельные совокупные столбцы для чтения-записи и транзакции только для чтения.

Требования ресурса могут также меняться в зависимости от операционного уровня изоляции. Однако, предполагая, что только один уровень изоляции использовался бы на сервере, агрегирование уровнем изоляции не обеспечено.

23.9.15.5. Сводная таблица ожидания объектов

Performance Schema поддерживает objects_summary_global_by_type для того, чтобы соединить события ожидания объектов.

Резюме событий в качестве примера:

mysql> SELECT * FROM objects_summary_global_by_type\G
...
*************************** 3. row ***************************
   OBJECT_TYPE: TABLE
 OBJECT_SCHEMA: test
   OBJECT_NAME: t
COUNT_STAR: 3
SUM_TIMER_WAIT: 263126976
MIN_TIMER_WAIT: 1522272
AVG_TIMER_WAIT: 87708678
MAX_TIMER_WAIT: 258428280
...
*************************** 10. row ***************************
   OBJECT_TYPE: TABLE
 OBJECT_SCHEMA: mysql
   OBJECT_NAME: user
COUNT_STAR: 14
SUM_TIMER_WAIT: 365567592
MIN_TIMER_WAIT: 1141704
AVG_TIMER_WAIT: 26111769
MAX_TIMER_WAIT: 334783032
...

У objects_summary_global_by_type есть эти столбцы группировки, чтобы указать как табличные события объединены: OBJECT_TYPE, OBJECT_SCHEMA и OBJECT_NAME. Каждая строка суммирует события для данного объекта.

objects_summary_global_by_type имеет те же самые сводные столбцы, как events_waits_summary_by_xxx. См. раздел 23.9.15.1.

У objects_summary_global_by_type есть эти индексы:

  • Первичный ключ на (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME).

TRUNCATE TABLE позволен для сводной таблицы объекта. Это сбрасывает сводные столбцы к нолю вместо того, чтобы удалить строки.

23.9.15.6. Сводные таблицы ввода/вывода файла

Performance Schema поддерживает сводные таблицы ввода/вывода файла.

Информация о резюме событий ввода/вывода файла в качестве примера:

mysql> SELECT * FROM file_summary_by_event_name\G
...
*************************** 2. row ***************************
   EVENT_NAME: wait/io/file/sql/binlog
   COUNT_STAR: 31
 SUM_TIMER_WAIT: 8243784888
 MIN_TIMER_WAIT: 0
 AVG_TIMER_WAIT: 265928484
 MAX_TIMER_WAIT: 6490658832
...
mysql> SELECT * FROM file_summary_by_instance\G
...
*************************** 2. row ***************************
FILE_NAME: /var/mysql/share/english/errmsg.sys
   EVENT_NAME: wait/io/file/sql/ERRMSG
   EVENT_NAME: wait/io/file/sql/ERRMSG
OBJECT_INSTANCE_BEGIN: 4686193384
   COUNT_STAR: 5
 SUM_TIMER_WAIT: 13990154448
 MIN_TIMER_WAIT: 26349624
 AVG_TIMER_WAIT: 2798030607
 MAX_TIMER_WAIT: 8150662536
...

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

  • file_summary_by_event_name имеет столбец EVENT_NAME. Каждая строка суммирует события для данного имени событий.

  • file_summary_by_instance имеет столбцы FILE_NAME, EVENT_NAME и OBJECT_INSTANCE_BEGIN. Каждая строка суммирует события для данного файла и имени событий.

У каждой сводной таблицы ввода/вывода файла есть следующие сводные столбцы, содержащие соединенные значения. Некоторые столбцы являются более общими и имеют значения, которые являются тем же самым, как сумма более узконаправленных столбцов. Таким образом, данные в более высоких уровнях доступны непосредственно без потребности в определяемых пользователем представлениях, которые суммируют столбцы низшего уровня.

  • COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT.

    Эти столбцы агрегируют все операции ввода/вывода.

  • COUNT_READ, SUM_TIMER_READ, MIN_TIMER_READ, AVG_TIMER_READ, MAX_TIMER_READ, SUM_NUMBER_OF_BYTES_READ.

    Эти столбцы агрегируют все операции чтения, включая FGETS, FGETC, FREAD и READ.

  • COUNT_WRITE, SUM_TIMER_WRITE, MIN_TIMER_WRITE, AVG_TIMER_WRITE, MAX_TIMER_WRITE, SUM_NUMBER_OF_BYTES_WRITE

    Эти столбцы агрегируют все операции записи, включая FPUTS, FPUTC, FPRINTF, VFPRINTF, FWRITE и PWRITE.

  • COUNT_MISC, SUM_TIMER_MISC, MIN_TIMER_MISC, AVG_TIMER_MISC, MAX_TIMER_MISC

    Эти столбцы агрегируют все другие операции ввода/вывода, включая CREATE, DELETE, OPEN, CLOSE, STREAM_OPEN, STREAM_CLOSE, SEEK, TELL, FLUSH, STAT, FSTAT, CHSIZE, RENAME и SYNC. Нет никаких счетчиков байтов для этих операций.

Сводные таблицы ввода/вывода файла имеют индексы:

TRUNCATE TABLE позволен для сводных таблиц ввода/вывода файла. Это сбрасывает сводные столбцы к нолю вместо того, чтобы удалить строки.

Сервер MySQL использует несколько методов, чтобы избежать операций ввода/вывода, кэшируя информацию, считанную из файлов, таким образом, возможно, что запросов, которых Вы могли бы ожидать, не будет. Вы можете быть в состоянии гарантировать, что ввод/вывод действительно происходит, сбрасывая кэши или перезапуская сервер, чтобы сбросить его состояние.

23.9.15.7. Сводные таблицы ввода/вывода и ожидания блокировки

Следующие разделы описывают табличный ввод/вывод и ожидание блокировки:

23.9.15.7.1. Таблица table_io_waits_summary_by_table

table_io_waits_summary_by_table собирает весь табличный ввод/вывод, произведенный инструментом wait/io/table/sql/handler. Группировка таблицей.

table_io_waits_summary_by_table имеет эти столбцы группировки, чтобы указать как табличные события объединены: OBJECT_TYPE, OBJECT_SCHEMA и OBJECT_NAME. У этих столбцов есть то же самое значение, как в events_waits_current . Они идентифицируют таблицу, к которой применяется строка.

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

  • COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT.

    Эти столбцы собирают все операции ввода/вывода. Они то же самое, как сумма столбцов xxx_READ и xxx_WRITE.

  • COUNT_READ, SUM_TIMER_READ, MIN_TIMER_READ, AVG_TIMER_READ, MAX_TIMER_READ.

    Эти столбцы собирают все операции чтения. Они то же самое, как сумма столбцов xxx_FETCH.

  • COUNT_WRITE, SUM_TIMER_WRITE, MIN_TIMER_WRITE, AVG_TIMER_WRITE, MAX_TIMER_WRITE.

    Эти столбцы собирают все операции записи. Они то же самое, как сумма столбцов xxx_INSERT, xxx_UPDATE и xxx_DELETE.

  • COUNT_FETCH, SUM_TIMER_FETCH, MIN_TIMER_FETCH, AVG_TIMER_FETCH, MAX_TIMER_FETCH

    Эти столбцы собирают все операции получения.

  • COUNT_INSERT, SUM_TIMER_INSERT, MIN_TIMER_INSERT, AVG_TIMER_INSERT, MAX_TIMER_INSERT

    Эти столбцы собирают все операции вставки.

  • COUNT_UPDATE, SUM_TIMER_UPDATE, MIN_TIMER_UPDATE, AVG_TIMER_UPDATE, MAX_TIMER_UPDATE

    Эти столбцы собирают все операции обновления.

  • COUNT_DELETE, SUM_TIMER_DELETE, MIN_TIMER_DELETE, AVG_TIMER_DELETE, MAX_TIMER_DELETE

    Эти столбцы собирают все операции удаления.

У table_io_waits_summary_by_table есть эти индексы:

  • Индекс Unique на (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME).

TRUNCATE TABLE разрешен для табличных сводных таблиц ввода/вывода. Это сбрасывает сводные столбцы к нолю вместо того, чтобы удалить строки. Усечение этой таблицы также усекает table_io_waits_summary_by_index_usage.

23.9.15.7.2. Таблица table_io_waits_summary_by_index_usage

table_io_waits_summary_by_index_usage собирает все события ожидания ввода/вывода индексов как произведено инструментом wait/io/table/sql/handler. Группировка по индексу таблицы.

Столбцы table_io_waits_summary_by_index_usage почти идентичны table_io_waits_summary_by_table. Единственная разница: дополнительный групповой столбец INDEX_NAME, который соответствует названию индекса, который использовался, когда случай ожидания табличного ввода/вывода был зарегистрирован:

  • Значение PRIMARY указывает, что табличный ввод/вывод использовал первичный индекс.

  • Значение NULL указывает, что табличный ввод/вывод не использовал индекс.
  • Вставки сосчитаны с учетом INDEX_NAME = NULL.

У table_io_waits_summary_by_index_usage есть эти индексы:

  • Индекс Unique на (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME, INDEX_NAME)

TRUNCATE TABLE разрешен для сводных таблиц ввода/вывода. Это сбрасывает сводные столбцы к нолю вместо того, чтобы удалить строки. Эта таблица является также усеченной усечением table_io_waits_summary_by_table. Операция DDL, которая изменяет индексную структуру таблицы, может вызвать сброс статистики индексов.

23.9.15.7.3. Таблица table_lock_waits_summary_by_table

table_lock_waits_summary_by_table собирает все события ожидания табличной блокировки как произведено инструментом wait/lock/table/sql/handler. Группировка по таблице.

Эта таблица содержит информацию о внутренних и внешних блокировках:

  • Внутренняя блокировка соответствует блокировке в уровне SQL. Это в настоящее время осуществляется вызовом thr_lock(). В строках событий эти блокировки отличаются столбцом OPERATION, у которого есть одно из этих значений:

    read normal
    read with shared locks
    read high priority
    read no insert
    write allow write
    write concurrent insert
    write delayed
    write low priority
    write normal
    
  • Внешняя блокировка соответствует блокировке в уровне механизма хранения. Это в настоящее время осуществляется вызовом handler::external_lock(). В строках событий эти блокировки отличаются столбцом OPERATION, у которого есть одно из этих значений:
    read external
    write external
    

У table_lock_waits_summary_by_table есть эти столбцы группировки, чтобы указать как табличные события объединяются: OBJECT_TYPE, OBJECT_SCHEMA и OBJECT_NAME. У этих столбцов есть то же самое значение, как в events_waits_current . Они идентифицируют таблицу, к которой применяется строка.

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

  • COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

    Эти столбцы агрегируют все операции блокировки. Они то же самое, как сумма соответствующих столбцов xxx_READ и xxx_WRITE.

  • COUNT_READ, SUM_TIMER_READ, MIN_TIMER_READ, AVG_TIMER_READ, MAX_TIMER_READ

    Эти столбцы агрегируют все операции блокировки чтения. Они то же самое, как сумма соответствующих столбцов xxx _READ_NORMAL, xxx_READ_WITH_SHARED_LOCKS , xxx_READ_HIGH_PRIORITY и xxx_READ_NO_INSERT.

  • COUNT_WRITE, SUM_TIMER_WRITE, MIN_TIMER_WRITE, AVG_TIMER_WRITE, MAX_TIMER_WRITE

    Эти столбцы агрегируют все операции блокировки записи. Они то же самое, как сумма соответствующих столбцов xxx_WRITE_ALLOW_WRITE, xxx_WRITE_CONCURRENT_INSERT, xxx_WRITE_LOW_PRIORITY и xxx_WRITE_NORMAL.

  • COUNT_READ_NORMAL, SUM_TIMER_READ_NORMAL, MIN_TIMER_READ_NORMAL, AVG_TIMER_READ_NORMAL, MAX_TIMER_READ_NORMAL

    Эти столбцы агрегируют все внутренние блокировки чтения.

  • COUNT_READ_WITH_SHARED_LOCKS, SUM_TIMER_READ_WITH_SHARED_LOCKS, MIN_TIMER_READ_WITH_SHARED_LOCKS, AVG_TIMER_READ_WITH_SHARED_LOCKS, MAX_TIMER_READ_WITH_SHARED_LOCKS

    Эти столбцы агрегируют все внутренние блокировки чтения.

  • COUNT_READ_HIGH_PRIORITY, SUM_TIMER_READ_HIGH_PRIORITY, MIN_TIMER_READ_HIGH_PRIORITY, AVG_TIMER_READ_HIGH_PRIORITY, MAX_TIMER_READ_HIGH_PRIORITY

    Эти столбцы агрегируют все внутренние блокировки чтения.

  • COUNT_READ_NO_INSERT, SUM_TIMER_READ_NO_INSERT, MIN_TIMER_READ_NO_INSERT, AVG_TIMER_READ_NO_INSERT, MAX_TIMER_READ_NO_INSERT

    Эти столбцы агрегируют все внутренние блокировки чтения.

  • COUNT_READ_EXTERNAL, SUM_TIMER_READ_EXTERNAL, MIN_TIMER_READ_EXTERNAL, AVG_TIMER_READ_EXTERNAL, MAX_TIMER_READ_EXTERNAL

    Эти столбцы агрегируют все внешние блокировки чтения.

  • COUNT_WRITE_ALLOW_WRITE, SUM_TIMER_WRITE_ALLOW_WRITE, MIN_TIMER_WRITE_ALLOW_WRITE, AVG_TIMER_WRITE_ALLOW_WRITE, MAX_TIMER_WRITE_ALLOW_WRITE

    Эти столбцы агрегируют все внутренние блокировки записи.

  • COUNT_WRITE_CONCURRENT_INSERT, SUM_TIMER_WRITE_CONCURRENT_INSERT, MIN_TIMER_WRITE_CONCURRENT_INSERT, AVG_TIMER_WRITE_CONCURRENT_INSERT, MAX_TIMER_WRITE_CONCURRENT_INSERT

    Эти столбцы агрегируют все внутренние блокировки записи.

  • COUNT_WRITE_LOW_PRIORITY, SUM_TIMER_WRITE_LOW_PRIORITY, MIN_TIMER_WRITE_LOW_PRIORITY, AVG_TIMER_WRITE_LOW_PRIORITY, MAX_TIMER_WRITE_LOW_PRIORITY

    Эти столбцы агрегируют все внутренние блокировки записи.

  • COUNT_WRITE_NORMAL, SUM_TIMER_WRITE_NORMAL, MIN_TIMER_WRITE_NORMAL, AVG_TIMER_WRITE_NORMAL, MAX_TIMER_WRITE_NORMAL.

    Эти столбцы агрегируют все внутренние блокировки записи.

  • COUNT_WRITE_EXTERNAL, SUM_TIMER_WRITE_EXTERNAL, MIN_TIMER_WRITE_EXTERNAL, AVG_TIMER_WRITE_EXTERNAL, MAX_TIMER_WRITE_EXTERNAL

    Эти столбцы агрегируют все внешние блокировки записи.

У table_lock_waits_summary_by_table есть эти индексы:

  • Индекс Unique на (OBJECT_TYPE, OBJECT_SCHEMA, OBJECT_NAME).

TRUNCATE TABLE разрешен для сводных таблиц блокировки. Это сбрасывает сводные столбцы к нолю вместо того, чтобы удалить строки.

23.9.15.8. Сводные таблицы сокета

Эти сводные таблицы сокета агрегируют информацию таймера и число байт для операций сокета:

  • socket_summary_by_event_name: Собирает статистику с инструментов wait/io/socket/* для всех операций ввода/вывода сокета на инструмент сокета.

  • socket_summary_by_instance: Собирает статистику с инструментов wait/io/socket/* для всех операций ввода/вывода сокета случай сокета. Когда соединение заканчивается, строка в socket_summary_by_instance удалена.

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

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

  • socket_summary_by_event_name имеет столбец EVENT_NAME. Каждая строка суммирует события для данного имени событий.

  • socket_summary_by_instance имеет столбец OBJECT_INSTANCE_BEGIN. Каждая строка суммирует события для данного объекта.

У каждой сводной таблицы сокета есть эти сводные столбцы, содержащие соединенные значения:

  • COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT

    Эти столбцы агрегируют все операции.

  • COUNT_READ, SUM_TIMER_READ, MIN_TIMER_READ, AVG_TIMER_READ, MAX_TIMER_READ, SUM_NUMBER_OF_BYTES_READ

    Эти столбцы агрегируют все операции получения (RECV, RECVFROM и RECVMSG).

  • COUNT_WRITE, SUM_TIMER_WRITE, MIN_TIMER_WRITE, AVG_TIMER_WRITE, MAX_TIMER_WRITE, SUM_NUMBER_OF_BYTES_WRITE

    Эти столбцы агрегируют все операции передачи (SEND, SENDTO и SENDMSG).

  • COUNT_MISC, SUM_TIMER_MISC, MIN_TIMER_MISC, AVG_TIMER_MISC, MAX_TIMER_MISC

    Эти столбцы агрегируют все прочие операции, такие как CONNECT, LISTEN, ACCEPT, CLOSE и SHUTDOWN. Нет никаких счетчиков байтов для этих операций.

socket_summary_by_instance также имеет столбец EVENT_NAME, который указывает на класс сокета: client_connection, server_tcpip_socket, server_unix_socket. Этот столбец может быть сгруппирован на изоляцию, например, деятельность клиента, от которого сервер слушает сокеты.

Сводные таблицы сокета имеют индексы:

TRUNCATE TABLE позволен на сводных таблицах сокета. За исключением events_statements_summary_by_digest это сбрасывает сводные столбцы к нолю вместо того, чтобы удалить строки.

23.9.15.9. Сводные таблицы памяти

Инструментальное использование памяти Performance Schema и статистика использования памяти детализирована этими факторами:

  • Тип используемой памяти (различные кэши, внутренние буферы и т.д).

  • Поток, учетная запись, пользователь, хост.

Performance Schema инструментует следующие аспекты использования памяти:

  • Размеры памяти.

  • Количество работы.
  • Нижняя и верхняя метки.

Размеры памяти помогают понять или настроить потребление памяти сервером.

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

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

Сводные таблицы памяти не содержат информацию о синхронизации, потому что события памяти не рассчитаны.

Информация о резюме событий памяти в качестве примера:

mysql> SELECT * FROM memory_summary_global_by_event_name
                   WHERE EVENT_NAME = 'memory/sql/TABLE'\G
*************************** 1. row ***************************
EVENT_NAME: memory/sql/TABLE
 COUNT_ALLOC: 1381
COUNT_FREE: 924
   SUM_NUMBER_OF_BYTES_ALLOC: 2059873
SUM_NUMBER_OF_BYTES_FREE: 1407432
  LOW_COUNT_USED: 0
CURRENT_COUNT_USED: 457
 HIGH_COUNT_USED: 461
LOW_NUMBER_OF_BYTES_USED: 0
CURRENT_NUMBER_OF_BYTES_USED: 652441
   HIGH_NUMBER_OF_BYTES_USED: 669269

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

  • memory_summary_by_account_by_event_name имеет столбцы USER, HOST и EVENT_NAME. Каждая строка суммирует события для сделанного отчета (комбинация пользователя и узла) и имя событий.

  • memory_summary_by_host_by_event_name имеет столбцы HOST и EVENT_NAME. Каждая строка суммирует события для данного узла и имени событий.
  • memory_summary_by_thread_by_event_name имеет столбцы THREAD_ID и EVENT_NAME. Каждая строка суммирует события для данного потока и имени событий.
  • memory_summary_by_user_by_event_name имеет столбцы USER и EVENT_NAME. Каждая строка суммирует события для данного пользователя и имени событий.
  • memory_summary_global_by_event_name имеет столбец EVENT_NAME. Каждая строка суммирует события для данного имени событий.

У каждой сводной таблицы памяти есть эти сводные столбцы, содержащие соединенные значения:

  • COUNT_ALLOC, COUNT_FREE

    Соединенные числа вызовов функций, подобных malloc и free.

  • SUM_NUMBER_OF_BYTES_ALLOC, SUM_NUMBER_OF_BYTES_FREE

    Соединенные размеры выделенных и освобожденных блоков памяти.

  • CURRENT_COUNT_USED

    Соединенное число в настоящее время выделяемых блоков, которые еще не были освобождены. Это столбец удобства, равный COUNT_ALLOC - COUNT_FREE.

  • CURRENT_NUMBER_OF_BYTES_USED

    Соединенный размер в настоящее время выделяемых блоков памяти, которые еще не были освобождены. Это столбец удобства, равный SUM_NUMBER_OF_BYTES_ALLOC-SUM_NUMBER_OF_BYTES_FREE.

  • LOW_COUNT_USED, HIGH_COUNT_USED

    Метки, соответствующие столбцу CURRENT_COUNT_USED.

  • LOW_NUMBER_OF_BYTES_USED, HIGH_NUMBER_OF_BYTES_USED

    Метки, соответствующие столбцу CURRENT_NUMBER_OF_BYTES_USED.

Сводные таблицы памяти имеют индексы:

TRUNCATE TABLE позволен на сводных таблицах памяти. Это имеет эффекты:

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

  • COUNT_ALLOC и COUNT_FREE сброшены к новой базовой линии, уменьшая каждый счетчик тем же самым значением.
  • Аналогично SUM_NUMBER_OF_BYTES_ALLOC и SUM_NUMBER_OF_BYTES_FREE сброшены к новой базовой линии.
  • LOW_COUNT_USED и HIGH_COUNT_USED сброшены к CURRENT_COUNT_USED.
  • LOW_NUMBER_OF_BYTES_USED и HIGH_NUMBER_OF_BYTES_USED сброшены к CURRENT_NUMBER_OF_BYTES_USED.

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

Поведение инструментовки памяти

Большинство инструментов памяти отключено по умолчанию и может быть включено или отключено динамически, обновляя столбец ENABLED соответствующих инструментов в setup_instruments . У инструментов памяти есть названия формы memory/code_area/instrument_name .

Чтобы включить все инструменты памяти, выполните этот запрос:

mysql> UPDATE setup_instruments SET ENABLED='YES'
                 WHERE NAME LIKE 'memory/%';

Инструменты с приставкой memory/performance_schema/ показывают, сколько памяти выделено для внутренних буферов в Performance Schema непосредственно. Инструменты memory/performance_schema/ встроены, всегда включаются и не могут быть отключены при запуске или во время выполнения. Встроенные инструменты памяти выведены на экран только в таблице memory_summary_global_by_event_name.

Для инструментов памяти столбец TIMED в setup_instruments проигнорирован, потому что операции памяти не рассчитаны.

Когда поток в сервере выполняет распределение памяти, которое было инструментовано, эти правила применяются:

  • Если поток не инструментован или инструмент памяти не включен, выделенный блок памяти не инструментован.

  • Иначе (то есть, поток и инструмент включены), выделенный блок памяти инструментован.

Для освобождения применяются эти правила:

  • Если поток инструментован, а блок памяти не инструментован, освобождение не инструментовано, никакие статистические данные не изменены.

  • Если поток не инструментован, а блок памяти инструментован, освобождение инструментовано, статистические данные изменены.

Для статистики по потокам применяются следующие правила.

Когда инструментованный блок памяти размера N выделен, Performance Schema делает эти обновления столбцов сводной таблицы памяти:

  • COUNT_ALLOC: увеличен на 1.

  • CURRENT_COUNT_USED: увеличен на 1.
  • HIGH_COUNT_USED: увеличен, если CURRENT_COUNT_USED новый максимум.
  • SUM_NUMBER_OF_BYTES_ALLOC: увеличен на N.
  • CURRENT_NUMBER_OF_BYTES_USED: увеличен на N.
  • HIGH_NUMBER_OF_BYTES_USED: увеличен, если CURRENT_NUMBER_OF_BYTES_USED новый максимум.

Когда инструментованный блок памяти освобожден, Performance Schema делает эти обновления столбцов сводной таблицы памяти:

  • COUNT_FREE: увеличен на 1.

  • CURRENT_COUNT_USED: уменьшен на 1.
  • LOW_COUNT_USED: уменьшена, если CURRENT_COUNT_USED новый минимум.
  • SUM_NUMBER_OF_BYTES_FREE: увеличен на N.
  • CURRENT_NUMBER_OF_BYTES_USED: уменьшен на N.
  • LOW_NUMBER_OF_BYTES_USED: уменьшен, если CURRENT_NUMBER_OF_BYTES_USED новый минимум.

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

  • LOW_COUNT_USED и LOW_NUMBER_OF_BYTES_USED более низкие оценки. Значение, о котором сообщает Performance Schema, будет меньше чем или равно самому низкому размеру памяти, эффективно используемой во время выполнения.

  • HIGH_COUNT_USED и HIGH_NUMBER_OF_BYTES_USED более высокие оценки. Значение, о котором сообщает Performance Schema, будет больше чем или равным самому высокому размеру памяти, эффективно используемой во время выполнения.

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

Вот пример оценочного вычисления, отметьте, что оценочное выполнение подвержено изменениям:

Поток 1 использует память в диапазоне от 1 МБ до 2 МБ во время выполнения, как сообщают столбцы LOW_NUMBER_OF_BYTES_USED и HIGH_NUMBER_OF_BYTES_USED в memory_summary_by_thread_by_event_name.

Поток 2 использует память в диапазоне от 10 МБ до 12 МБ во время выполнения.

Когда эти два потока принадлежат той же самой учетной записи пользователя, резюме на учетную запись оценивает, что эта учетная запись использовала память в диапазоне от 11 МБ до 14 МБ. Таким образом, LOW_NUMBER_OF_BYTES_USED как высокоуровневая совокупность это сумма всех LOW_NUMBER_OF_BYTES_USED (принятие худшего случая). Аналогично HIGH_NUMBER_OF_BYTES_USED как высокоуровневая совокупность это сумма всех HIGH_NUMBER_OF_BYTES_USED (принятие худшего случая).

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

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

Реальное использование памяти для этой учетной записи, возможно, было в диапазоне от 11.5MB до 13.5MB.

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

23.9.15.10. Сводные таблицы ошибок

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

Сбором информации об ошибке управляет инструмент error, который включен по умолчанию. Информация синхронизации не собрана.

У каждой сводной таблицы есть три столбца, которые идентифицируют ошибку:

  • ERROR_NUMBER числовое значение ошибки. Значение уникально.

  • ERROR_NAME символическое имя, соответствующее ERROR_NUMBER. Значение уникально.
  • SQLSTATE значение SQLSTATE, соответствующее ERROR_NUMBER. Значение не обязательно уникально.

Например, если ERROR_NUMBER 1050, ERROR_NAME ER_TABLE_EXISTS_ERROR и SQLSTATE 42S01.

Информация о резюме событий в качестве примера:

mysql> SELECT * FROM events_errors_summary_global_by_error
                   WHERE SUM_ERROR_RAISED <> 0\G
*************************** 1. row ***************************
 ERROR_NUMBER: 1064
 ERROR_NAME: ER_PARSE_ERROR
  SQL_STATE: 42000
 SUM_ERROR_RAISED: 1
SUM_ERROR_HANDLED: 0
 FIRST_SEEN: 2016-06-28 07:34:02
  LAST_SEEN: 2016-06-28 07:34:02
*************************** 2. row ***************************
 ERROR_NUMBER: 1146
 ERROR_NAME: ER_NO_SUCH_TABLE
  SQL_STATE: 42S02
 SUM_ERROR_RAISED: 2
SUM_ERROR_HANDLED: 0
 FIRST_SEEN: 2016-06-28 07:34:05
  LAST_SEEN: 2016-06-28 07:36:18
*************************** 3. row ***************************
 ERROR_NUMBER: 1317
 ERROR_NAME: ER_QUERY_INTERRUPTED
  SQL_STATE: 70100
 SUM_ERROR_RAISED: 1
SUM_ERROR_HANDLED: 0
 FIRST_SEEN: 2016-06-28 11:01:49
  LAST_SEEN: 2016-06-28 11:01:49

У каждой сводной таблицы есть один или более группирующихся столбцов, чтобы указать как табличные ошибки объединяются:

  • events_errors_summary_by_account_by_error имеет столбцы USER, HOST и ERROR_NUMBER. Каждая строка суммирует события для сделанного отчета (комбинация пользователя и узла) и ошибки.

  • events_errors_summary_by_host_by_error имеет столбцы HOST и ERROR_NUMBER. Каждая строка суммирует события для данного узла и ошибки.
  • events_errors_summary_by_thread_by_error имеет столбцы THREAD_ID и ERROR_NUMBER. Каждая строка суммирует события для данного потока и ошибки.
  • events_errors_summary_by_user_by_error имеет столбцы USER и ERROR_NUMBER. Каждая строка суммирует события для данного пользователя и ошибки.
  • events_errors_summary_global_by_error имеет столбец ERROR_NUMBER. Каждая строка суммирует события для данной ошибки.

У каждой сводной таблицы есть эти сводные столбцы, содержащие соединенные значения:

  • SUM_ERROR_RAISED

    Этот столбец показывает, сколько раз ошибка произошла.

  • SUM_ERROR_HANDLED

    Этот столбец показывает, сколько раз ошибка была обработана обработчиком исключения SQL.

  • FIRST_SEEN, LAST_SEEN

    Timestamp, указывающий, когда ошибка была замечена в первый и в последний раз.

Строка NULL в каждой сводной таблице нужна для совокупной статистики для всех ошибок, которые лежат вне диапазона инструментованных ошибок. Например, если ошибки MySQL Server находятся в диапазоне от M до N и ошибка поднята с номером Q не в этом диапазоне, ошибка показана в строке NULL. Это строка с ERROR_NUMBER=0, ERROR_NAME=NULL и SQLSTATE=NULL.

Сводные таблицы ошибок имеют индексы:

TRUNCATE TABLE позволен на сводных таблицах ошибок. Это имеет эффекты:

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

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

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

23.9.15.11. Сводные таблицы переменных состояния

Значение системной переменной show_compatibility_56 затрагивает информацию, доступную из таблиц, описанных здесь. Для деталей см. описание этой переменной в разделе 6.1.5.

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

  • status_by_account имеет столбцы USER, HOST и VARIABLE_NAME, чтобы суммировать переменные состояния учетной записью.

  • status_by_host имеет столбцы HOST и VARIABLE_NAME, чтобы суммировать переменные состояния узлом, от которого соединялись клиенты.
  • status_by_user имеет столбцы USER и VARIABLE_NAME, чтобы суммировать переменные состояния именем пользователя клиента.

У каждой сводной таблицы переменных состояния есть этот сводный столбец, содержащий соединенные значения:

  • VARIABLE_VALUE

    Соединенное значение переменной состояния для активных и законченных сеансов.

Сводные таблицы переменной состояния имеют индексы:

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

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

Учетная запись, узел и пользовательская статистика не собраны, если переменные performance_schema_accounts_size, performance_schema_hosts_size и performance_schema_users_size, соответственно, установлены в 0.

Performance Schema поддерживает TRUNCATE TABLE для сводных таблиц переменных состояния следующим образом, во всех случаях состояние для активных сеансов не затронуто:

  • status_by_account: Совокупности считают состояние от законченных сеансов до пользователя и размещают состояние, затем сбрасывает состояние учетной записи.

  • status_by_host: Сброс состояний узла от законченных сеансов.
  • status_by_user: Сброс состояний пользователя от законченных сеансов.

FLUSH STATUS добавляет состояние сеанса от всех активных сеансов к глобальным переменным состояния, сбрасывает состояние всех активных сеансов и сбрасывает учетную запись, узел и пользовательские значения состояния от разъединенных сеансов.

23.9.16. Прочие таблицы Performance Schema

Следующие разделы описывают таблицы, которые не попадают в табличные категории, обсужденные в предыдущих разделах:

  • host_cache: Информация от внутреннего кэша узла.

  • performance_timers : Какие таймеры событий доступны.
  • threads: Информация о потоках сервера.

23.9.16.1. Таблица host_cache

Таблица host_cache обеспечивает доступ к содержанию кэша узла, который содержит имя хоста клиента и информацию об IP-адресе и используется, чтобы избежать поисков DNS (см. раздел 9.12.4.2). host_cache выставляет содержание кэша узла так, чтобы это могло быть исследовано, используя SELECT. Performance Schema должна быть включена, или эта таблица пуста.

У host_cache есть эти столбцы:

  • IP

    IP-адрес клиента, который соединялся с сервером, выраженный как строка.

  • HOST

    Имя хоста DNS для IP клиента или NULL, если имя неизвестно.

  • HOST_VALIDATED

    Было ли разрешение DNS "имя к IP" или "IP к узлу" выполнено успешно для IP клиента. Если HOST_VALIDATED = YES, HOST используется в качестве имени хоста, соответствующего IP так, чтобы вызовов DNS можно было избежать. В то время, как HOST_VALIDATED = NO, разрешение DNS предпринято снова для каждого соединения, пока оно в конечном счете не завершается с допустимым результатом или с постоянной ошибкой. Эта информация позволяет серверу избежать плохого кэширования или пропуска имени хоста во время временных отказов DNS, которые затронули бы клиентов навсегда.

  • SUM_CONNECT_ERRORS

    Число ошибок соединения, которые считаются blocking (оценены относительно переменной max_connect_errors ). Только ошибки квитирования протокола посчитаны и только для узлов, которые передали проверку допустимости (HOST_VALIDATED = YES).

  • COUNT_HOST_BLOCKED_ERRORS

    Число соединений, которые были заблокированы потому, что SUM_CONNECT_ERRORS превышает значение переменной of the max_connect_errors.

  • COUNT_NAMEINFO_TRANSIENT_ERRORS

    Число переходных ошибок во время разрешения DNS IP к имени хоста.

  • COUNT_NAMEINFO_PERMANENT_ERRORS

    Число постоянных ошибок во время разрешения DNS IP к имени хоста.

  • COUNT_FORMAT_ERRORS

    Число ошибок формата имени хоста. MySQL не выполняет соответствие значения столбцов Host в mysql.user именам хоста, для которых один или больше начальных компонентов имени являются полностью числовыми (1.2.example.com). IP-адрес клиента используется вместо этого. Для объяснения, почему этот тип соответствия не происходит, см. раздел 7.2.3.

  • COUNT_ADDRINFO_TRANSIENT_ERRORS

    Число переходных ошибок во время разрешения DNS имени хоста к IP.

  • COUNT_ADDRINFO_PERMANENT_ERRORS

    Число постоянных ошибок во время разрешения DNS имени хоста к IP.

  • COUNT_FCRDNS_ERRORS

    Число передовых подтвержденных обратных ошибок DNS. Эти ошибки происходят, когда разрешение DNS производит IP-адрес, который не соответствует клиенту, порождающему IP-адрес.

  • COUNT_HOST_ACL_ERRORS

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

  • COUNT_NO_AUTH_PLUGIN_ERRORS

    Число ошибок из-за запросов о недоступном плагине аутентификации. Плагин может быть недоступным, если, например, он никогда не загружался, или попытка загрузки провалилась.

  • COUNT_AUTH_PLUGIN_ERRORS

    Число ошибок, сообщенных плагинами аутентификации.

    Плагин аутентификации может сообщить, различные коды ошибки, которые указывают на первопричину отказа. В зависимости от типа ошибки увеличен один из этих столбцов: COUNT_AUTHENTICATION_ERRORS, COUNT_AUTH_PLUGIN_ERRORS, COUNT_HANDSHAKE_ERRORS. Новые коды возвращения это дополнительное расширение к существующему API. Неизвестные или неожиданные ошибки включены в столбец COUNT_AUTH_PLUGIN_ERRORS.

  • COUNT_HANDSHAKE_ERRORS

    Число ошибок обнаружено на проводном уровне протокола.

  • COUNT_PROXY_USER_ERRORS

    Число ошибок обнаружило, когда proxy-пользователь A передает доступ другому пользователю B, который не существует.

  • COUNT_PROXY_USER_ACL_ERRORS

    Число ошибок, когда proxy-пользователь A передает доступ другому пользователю B, который действительно существует, но для кого A не имеет привилегии PROXY.

  • COUNT_AUTHENTICATION_ERRORS

    Число ошибок вызвано неудавшейся аутентификацией.

  • COUNT_SSL_ERRORS

    Число ошибок из-за проблем SSL.

  • COUNT_MAX_USER_CONNECTIONS_ERRORS

    Число ошибок вызвано превышением доли соединения в расчёте на пользователя. См. раздел 7.3.5.

  • COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS

    Число ошибок вызвано, превышая доли соединений-за-час в расчёте на пользователя. См. раздел 7.3.5.

  • COUNT_DEFAULT_DATABASE_ERRORS

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

  • COUNT_INIT_CONNECT_ERRORS

    Число ошибок, вызванных отказами выполнения запросов в init_connect.

  • COUNT_LOCAL_ERRORS

    Число ошибок, локальных к выполнению сервера и не связанных с сетью, аутентификацией или разрешением. Например, условия переполнения памяти попадают в эту категорию.

  • COUNT_UNKNOWN_ERRORS

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

  • FIRST_SEEN

    timestamp первой попытки соединения, замеченной от клиента в IP.

  • LAST_SEEN

    timestamp последней попытки соединения, замеченной от клиента в IP.

  • FIRST_ERROR_SEEN

    timestamp первой ошибки, замеченной от клиента в IP.

  • LAST_ERROR_SEEN

    timestamp последней ошибки, замеченной от клиента в IP.

У host_cache есть эти индексы:

  • Первичный ключ на (IP).

  • Индекс на (HOST).

FLUSH HOSTS и TRUNCATE TABLE host_cache имеют тот же самый эффект: они очищают кэш узла. Это также удаляет строки из host_cache (потому что это видимое представление кэша) и открывает любые заблокированные узлы (см. раздел B.5.2.5). FLUSH HOSTS требует привилегии RELOAD. TRUNCATE TABLE требует привилегии DROP для host_cache.

23.9.16.2. Таблица performance_timers

performance_timers показывает, какие таймеры событий доступны:

mysql> SELECT * FROM performance_timers;
+-------------+-----------------+------------------+----------------+
| TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+-------------+-----------------+------------------+----------------+
| CYCLE       | 2389029850      | 1                | 72             |
| NANOSECOND  | 1000000000      | 1                | 112            |
| MICROSECOND |    1000000      | 1                | 136            |
| MILLISECOND |       1036      | 1                | 168            |
| TICK        |        105      | 1                | 2416           |
+-------------+-----------------+------------------+----------------+

Таймеры в setup_timers , которые Вы можете использовать, не имеют NULL в других столбцах. Если значения, связанные с данным именем таймера, NULL, этот таймер не поддержан на Вашей платформе.

У performance_timers есть эти столбцы:

  • TIMER_NAME

    Имя, которым можно обратиться к таймеру, конфигурируя setup_timers.

  • TIMER_FREQUENCY

    Число модулей таймера в секунду. Для счетчика циклов частота вообще связана со скоростью центрального процессора. Например, на системе с 2.4GHz процессором CYCLE может быть близко к 2400000000.

  • TIMER_RESOLUTION

    Указывает на число модулей таймера, которыми таймер оценивает увеличение. Если у таймера есть разрешение 10, его значение увеличено на 10 каждый раз.

  • TIMER_OVERHEAD

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

TRUNCATE TABLE не позволен для performance_timers.

23.9.16.3. Таблица threads

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

mysql> SELECT * FROM threads\G
*************************** 1. row ***************************
THREAD_ID: 1
   NAME: thread/sql/main
   TYPE: BACKGROUND
 PROCESSLIST_ID: NULL
   PROCESSLIST_USER: NULL
   PROCESSLIST_HOST: NULL
 PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: NULL
   PROCESSLIST_TIME: 80284
  PROCESSLIST_STATE: NULL
   PROCESSLIST_INFO: NULL
   PARENT_THREAD_ID: NULL
   ROLE: NULL
 INSTRUMENTED: YES
HISTORY: YES
CONNECTION_TYPE: NULL
 THREAD_OS_ID: 489803
...
*************************** 4. row ***************************
THREAD_ID: 51
   NAME: thread/sql/one_connection
   TYPE: FOREGROUND
 PROCESSLIST_ID: 34
   PROCESSLIST_USER: isabella
   PROCESSLIST_HOST: localhost
 PROCESSLIST_DB: performance_schema
PROCESSLIST_COMMAND: Query
   PROCESSLIST_TIME: 0
  PROCESSLIST_STATE: Sending data
   PROCESSLIST_INFO: SELECT * FROM threads
   PARENT_THREAD_ID: 1
   ROLE: NULL
 INSTRUMENTED: YES
HISTORY: YES
CONNECTION_TYPE: SSL/TLS
 THREAD_OS_ID: 755399
...

Когда Performance Schema инициализируется, она заполняет threads, основываясь на существующих потоках. После этого новая строка добавлена каждый раз, когда сервер создает поток.

Столбцы INSTRUMENTED и HISTORY для новых потоков определены содержанием setup_actors. Для информации о том, как использовать setup_actors, чтобы управлять этими столбцами, см. раздел 23.2.3.6.

Удаление строк из threads происходит, когда потоки заканчиваются. Для потока, связанного с сеансом клиента, происходит удаление, когда сеанс заканчивается. Если клиент имеет включенную опцию auto-reconnect, и сеанс повторно соединяется после разъединения, то этот сеанс становится связанным с новой строкой в threads, у которой есть другой PROCESSLIST_ID. Значения INSTRUMENTED и HISTORY для нового потока могут отличаться от таковых из оригинального потока: setup_actors, возможно, изменилась тем временем, и если INSTRUMENTED или HISTORY для оригинального потока было изменено после того, как строка была инициализирована, изменение не переносится на новый поток.

Столбцы таблицы threads с именами, имеющими приставку PROCESSLIST_, предоставляют информацию, подобную доступной из INFORMATION_SCHEMA.PROCESSLIST или SHOW PROCESSLIST . Таким образом, все три источника предоставляют контролирующую поток информацию. Использование threads отличается от использования других двух источников:

  • Доступ к threads не требует mutex и оказывает минимальное влияние на работу сервера. INFORMATION_SCHEMA.PROCESSLIST и SHOW PROCESSLIST имеют отрицательные исполнительные последствия, потому что они требуют mutex.

  • threads обеспечивает дополнительную информацию для каждого потока, такую как является ли это фоновым потоком и местоположение в пределах сервера, связанное с потоком.
  • threads предоставляет информацию о фоновых потоках, таким образом, она может использоваться, чтобы контролировать деятельность, чего другие источники информации о потоке не могут.
  • Вы можете включить или отключить контроль потока (то есть, инструментованы ли события, запущенные потоком и журналирование событий. Чтобы управлять начальным состоянием INSTRUMENTED и HISTORY для новых потоков переднего плана, используйте setup_actors. Чтобы управлять этими аспектами существующих потоков, установите столбцы INSTRUMENTED и HISTORY строк таблицы threads.

По этим причинам, DBA выполняет контроль сервера, используя INFORMATION_SCHEMA.PROCESSLIST или SHOW PROCESSLIST и может хотеть контролировать, используя вместо этого threads.

Для INFORMATION_SCHEMA.PROCESSLIST и SHOW PROCESSLIST информацию о потоках для других пользователей показывают, только если текущий пользователь имеет привилегию PROCESS. Это не так для таблицы threads : все строки показывают любому пользователю, который имеет привилегию SELECT для таблицы. Пользователям, которые не должны быть в состоянии видеть потоки для других пользователей, нельзя давать эту привилегию.

У threads есть эти столбцы:

  • THREAD_ID

    Уникальный идентификатор потока.

  • NAME

    Имя, связанное с кодом инструментовки потока в сервере. Например, thread/sql/one_connection соответствует функции потока в коде, ответственном за обработку пользовательского соединения, а thread/sql/main для функции main() сервера.

  • TYPE

    Тип потока: FOREGROUND или BACKGROUND. Пользовательские потоки соединения это потоки переднего плана. Потоки, связанные с внутренней деятельностью сервера, являются фоновыми потоками.

  • PROCESSLIST_ID

    Для потоков, которые выведены на экран в INFORMATION_SCHEMA.PROCESSLIST это значение столбца ID этой таблицы. Это также значение, выведенное на экран в столбце Id вывода SHOW PROCESSLIST и значение, возвращаемое функцией CONNECTION_ID() для потока.

    Для фоновых потоков (потоки, не связанные с пользовательским соединением), PROCESSLIST_ID NULL, таким образом, значения не уникальны.

  • PROCESSLIST_USER

    Пользователь, связанный с потоком переднего плана, NULL для фонового потока.

  • PROCESSLIST_HOST

    Имя хоста клиента, связанного с потоком переднего плана, NULL для фонового потока.

    В отличие от столбца HOST в INFORMATION_SCHEMA, PROCESSLIST или столбец Host вывода SHOW PROCESSLIST, столбец PROCESSLIST_HOST не включает номер порта для соединений TCP/IP. Чтобы получить эту информацию из Performance Schema, включите инструментовку сокета (которая не включена по умолчанию) и исследуйте таблицу socket_instances:

    mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'wait/io/socket%';
    +----------------------------------------+---------+-------+
    | NAME                                   | ENABLED | TIMED |
    +----------------------------------------+---------+-------+
    | wait/io/socket/sql/server_tcpip_socket | NO      | NO    |
    | wait/io/socket/sql/server_unix_socket  | NO      | NO    |
    | wait/io/socket/sql/client_connection   | NO      | NO    |
    +----------------------------------------+---------+-------+
    3 rows in set (0.01 sec)
    
    mysql> UPDATE setup_instruments SET ENABLED='YES'
                     WHERE NAME LIKE 'wait/io/socket%';
    Query OK, 3 rows affected (0.00 sec)
    Rows matched: 3  Changed: 3  Warnings: 0
    
    mysql> SELECT * FROM socket_instances\G
    *************************** 1. row ***************************
     EVENT_NAME: wait/io/socket/sql/client_connection
    OBJECT_INSTANCE_BEGIN: 140612577298432
    THREAD_ID: 31
    SOCKET_ID: 53
     IP: ::ffff:127.0.0.1
     PORT: 55642
    STATE: ACTIVE
    ...
    
  • PROCESSLIST_DB

    База данных значения по умолчанию для потока или NULL, если нет.

  • PROCESSLIST_COMMAND

    Для потоков переднего плана команда выполняется от имени клиента или Sleep, если сессия спит. Для описаний команд потока см. раздел 9.14. Значение этого столбца соответствует командам COM_xxx протокола клиент-сервер и переменным состояния Com_xxx. См. раздел 6.1.7.

    Фоновые потоки не выполняют команды от имени клиентов, таким образом, этот столбец может быть NULL.

  • PROCESSLIST_TIME

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

  • PROCESSLIST_STATE

    Действие, случай или состояние, которое указывает на то, что делает поток. Для описания значений PROCESSLIST_STATE см. раздел 9.14. Если значение NULL, поток может соответствовать неактивному сеансу клиента, или работа, которую он делает, не инструментована с этапами.

    Большинство состояний соответствует очень быстрым операциям. Если поток остается в данном статусе в течение многих секунд, может быть проблема.

  • PROCESSLIST_INFO

    Запрос, который поток выполняет, или NULL, если это не выполняет запросы. Запрос мог быть послан в сервер или внутренним запросом, если запрос выполняет другие запросы. Например, если CALL выполняет хранимую процедуру, которая выполняет SELECT, значение PROCESSLIST_INFO показывает запрос SELECT.

  • PARENT_THREAD_ID

    Если этот поток подпоток (порожденный другим потоком), это THREAD_ID основного потока.

  • ROLE

    Не используется.

  • INSTRUMENTED

    Инструментованы ли события, запущенные потоком. Значения YES или NO.

    • Для потоков переднего плана, начальное значение INSTRUMENTED определено тем, соответствует ли учетная запись пользователя, связанная с потоком, какой-либо строке в setup_actors. Соответствие основано на значениях PROCESSLIST_USER и PROCESSLIST_HOST.

      Если поток порождает подпоток, соответствие происходит снова для строки таблицы threads, созданной для подпотока.

    • Для фоновых потоков INSTRUMENTED YES по умолчанию. setup_actors не консультируется, потому что нет никакого связанного пользователя для фоновых потоков.
    • Для любого потока значение INSTRUMENTED может быть изменено во время жизни потока.

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

    • Потребитель thread_instrumentation в setup_consumers должен быть YES.

    • Столбец threads.INSTRUMENTED должен быть YES.
    • Контроль происходит только для событий потока, произведенных из инструментов, которые имеют столбец ENABLED YES в setup_instruments .

  • HISTORY

    Зарегистрировать ли исторические события для потока. Значения YES или NO.

    • Для потоков переднего плана, начальное значение HISTORY определено тем, соответствует ли учетная запись пользователя, связанная с потоком, какой-либо строке в setup_actors. Соответствие основано на значениях PROCESSLIST_USER и PROCESSLIST_HOST.

      Если поток порождает подпоток, соответствие происходит снова для строки таблицы threads, созданной для подпотока.

    • Для фоновых потоков HISTORY YES по умолчанию. setup_actors не консультируется, потому что нет никакого связанного пользователя для фоновых потоков.
    • Для любого потока значение HISTORY может быть изменено во время жизни потока.

    Для журналирования исторического события для потока, эти вещи должны быть истиной:

    • Соответствующие связанные с историей потребители в setup_consumers должны быть включены. Например, случай ожидания, протоколируемый в таблицах events_waits_history и events_waits_history_long требует соответствующих потребителй events_waits_history и events_waits_history_long в YES.

    • Столбец threads.HISTORY должен быть YES.
    • Журналирование происходит только для событий потока, произведенных из инструментов, которые имеют ENABLED YES в setup_instruments .

  • CONNECTION_TYPE

    Протокол, по которому установлено соединение, или NULL для фоновых потоков. Разрешенные значения: TCP/IP (соединение TCP/IP, установленное без SSL), SSL/TLS (соединение TCP/IP, установленное с SSL), Socket (соединение файла сокета Unix), Named Pipe (соединение канала Windows) и Shared Memory (соединение совместно используемой памяти Windows).

  • THREAD_OS_ID

    Поток или идентификатор задачи как определено основной операционной системой, если есть:

    • Когда поток MySQL связан с тем же самым потоком операционной системы, THREAD_OS_ID содержит ID потока операционной системы.

    • Когда поток MySQL не связан с тем же самым потоком операционной системы, THREAD_OS_ID NULL. Это типично для пользовательских сеансов, когда плагин потока используется (см. MySQL Enterprise Thread Pool).

    Для Windows THREAD_OS_ID соответствует ID потока, видимому в Process Explorer (https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx ).

    Для Linux THREAD_OS_ID соответствует значению функции gettid(). Это значение выставлено, например, используя команды perf или ps -L или в файловой системе proc (/proc/[pid]/task/[tid] ). Для получения дополнительной информации см. perf-stat(1), ps(1) и proc(5).

У threads есть эти индексы:

  • Первичный ключ на (THREAD_ID).

  • Индекс на (NAME).
  • Индекс на (PROCESSLIST_ID).
  • Индекс на (PROCESSLIST_USER, PROCESSLIST_HOST).
  • Индекс на (PROCESSLIST_HOST).
  • Индекс на (THREAD_OS_ID).

TRUNCATE TABLE не позволен для threads.

23.10. Обзор опций и переменных Performance Schema

Таблица 23.3. Обзор переменных Performance Schema

ИмяCmd-Line Файл опцийСистемная СтатуснаяОбласть действия Динамическая
performance_schemaДаДаДа ГлобальнаяНет
Performance_schema_accounts_lost ДаГлобальнаяНет
performance_schema_accounts_sizeДаДаДа ГлобальнаяНет
Performance_schema_cond_classes_lost ДаГлобальнаяНет
Performance_schema_cond_instances_lost ДаГлобальнаяНет
performance-schema-consumer-events-stages-currentДа Да
performance-schema-consumer-events-stages-historyДа Да
performance-schema-consumer-events-stages-history-longДа Да
performance-schema-consumer-events-statements-currentДа Да
performance-schema-consumer-events-statements-historyДа Да
performance-schema-consumer-events-statements-history-long ДаДа
performance-schema-consumer-events-transactions-currentДа Да
performance-schema-consumer-events-transactions-historyДа Да
performance-schema-consumer-events-transactions-history-long ДаДа
performance-schema-consumer-events-waits-currentДа Да
performance-schema-consumer-events-waits-historyДа Да
performance-schema-consumer-events-waits-history-longДа Да
performance-schema-consumer-global-instrumentationДа Да
performance-schema-consumer-statements-digestДаДа
performance-schema-consumer-thread-instrumentationДа Да
Performance_schema_digest_lost ДаГлобальнаяНет
performance_schema_digests_sizeДаДаДа ГлобальнаяНет
performance_schema_events_stages_history_long_sizeДа ДаДа ГлобальнаяНет
performance_schema_events_stages_history_sizeДаДа Да ГлобальнаяНет
performance_schema_events_statements_history_long_sizeДа ДаДа ГлобальнаяНет
performance_schema_events_statements_history_sizeДа ДаДа ГлобальнаяНет
performance_schema_events_transactions_history_long_sizeДа ДаДа ГлобальнаяНет
performance_schema_events_transactions_history_sizeДа ДаДа ГлобальнаяНет
performance_schema_events_waits_history_long_sizeДа ДаДа ГлобальнаяНет
performance_schema_events_waits_history_sizeДаДа Да ГлобальнаяНет
Performance_schema_file_classes_lost ДаГлобальнаяНет
Performance_schema_file_handles_lost ДаГлобальнаяНет
Performance_schema_file_instances_lost ДаГлобальнаяНет
Performance_schema_hosts_lost ДаГлобальнаяНет
performance_schema_hosts_sizeДаДаДа ГлобальнаяНет
performance-schema-instrumentДаДа
Performance_schema_locker_lost ДаГлобальнаяНет
performance_schema_max_cond_classesДаДаДа ГлобальнаяНет
performance_schema_max_cond_instancesДаДа Да ГлобальнаяНет
performance_schema_max_digest_lengthДаДа Да ГлобальнаяНет
performance_schema_max_file_classesДаДаДа ГлобальнаяНет
performance_schema_max_file_handlesДаДаДа ГлобальнаяНет
performance_schema_max_file_instancesДаДа Да ГлобальнаяНет
performance_schema_max_memory_classesДаДа Да ГлобальнаяНет
performance_schema_max_metadata_locksДаДа Да ГлобальнаяНет
performance_schema_max_mutex_classesДаДа Да ГлобальнаяНет
performance_schema_max_mutex_instancesДаДа Да ГлобальнаяНет
performance_schema_max_prepared_statements_instancesДа ДаДа ГлобальнаяНет
performance_schema_max_program_instancesДаДа Да ГлобальнаяНет
performance_schema_max_rwlock_classesДаДа Да ГлобальнаяНет
performance_schema_max_rwlock_instancesДаДа Да ГлобальнаяНет
performance_schema_max_socket_classesДаДа Да ГлобальнаяНет
performance_schema_max_socket_instancesДаДа Да ГлобальнаяНет
performance_schema_max_stage_classesДаДа Да ГлобальнаяНет
performance_schema_max_statement_classesДаДа Да ГлобальнаяНет
performance_schema_max_statement_stackДаДа Да ГлобальнаяНет
performance_schema_max_table_handlesДаДа Да ГлобальнаяНет
performance_schema_max_table_instancesДаДа Да ГлобальнаяНет
performance_schema_max_thread_classesДаДа Да ГлобальнаяНет
performance_schema_max_thread_instancesДаДа Да ГлобальнаяНет
Performance_schema_memory_classes_lost ДаГлобальнаяНет
Performance_schema_metadata_lock_lost ДаГлобальнаяНет
Performance_schema_mutex_classes_lost ДаГлобальнаяНет
Performance_schema_mutex_instances_lost ДаГлобальнаяНет
Performance_schema_nested_statement_lost ДаГлобальнаяНет
Performance_schema_prepared_statements_lost ДаГлобальнаяНет
Performance_schema_program_lost ДаГлобальнаяНет
Performance_schema_rwlock_classes_lost ДаГлобальнаяНет
Performance_schema_rwlock_instances_lost ДаГлобальнаяНет
Performance_schema_session_connect_attrs_lost ДаГлобальнаяНет
performance_schema_session_connect_attrs_sizeДаДа Да ГлобальнаяНет
performance_schema_setup_actors_sizeДаДа Да ГлобальнаяНет
performance_schema_setup_objects_sizeДаДа Да ГлобальнаяНет
Performance_schema_socket_classes_lost ДаГлобальнаяНет
Performance_schema_socket_instances_lost ДаГлобальнаяНет
Performance_schema_stage_classes_lost ДаГлобальнаяНет
Performance_schema_statement_classes_lost ДаГлобальнаяНет
Performance_schema_table_handles_lost ДаГлобальнаяНет
Performance_schema_table_instances_lost ДаГлобальнаяНет
Performance_schema_thread_classes_lost ДаГлобальнаяНет
Performance_schema_thread_instances_lost ДаГлобальнаяНет
Performance_schema_users_lost ДаГлобальнаяНет
performance_schema_users_sizeДаДаДа ГлобальнаяНет

23.11. Опции команд Performance Schema

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

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

  • --performance-schema-consumer-consumer_name=value

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

  • --performance-schema-instrument=instrument_name =value

    Сконфигурируйте инструмент Performance Schema. Имя может быть дано как образец, чтобы сконфигурировать инструменты, которые соответствуют образцу.

Следующие элементы конфигурируют отдельных потребителей:

23.12. Системные переменные Performance Schema

осуществляет несколько системных переменных, которые предоставляют информацию о конфигурации:

mysql> SHOW VARIABLES LIKE 'perf%';
+----------------------------------------------------------+-------+
| Variable_name                                            | Value |
+----------------------------------------------------------+-------+
| performance_schema                                       | ON    |
| performance_schema_accounts_size                         | -1    |
| performance_schema_digests_size                          | 10000 |
| performance_schema_events_stages_history_long_size       | 10000 |
| performance_schema_events_stages_history_size            | 10    |
| performance_schema_events_statements_history_long_size   | 10000 |
| performance_schema_events_statements_history_size        | 10    |
| performance_schema_events_transactions_history_long_size | 10000 |
| performance_schema_events_transactions_history_size      | 10    |
| performance_schema_events_waits_history_long_size        | 10000 |
| performance_schema_events_waits_history_size             | 10    |
| performance_schema_hosts_size                            | -1    |
| performance_schema_max_cond_classes                      | 80    |
| performance_schema_max_cond_instances                    | -1    |
| performance_schema_max_digest_length                     | 1024  |
| performance_schema_max_file_classes                      | 50    |
| performance_schema_max_file_handles                      | 32768 |
| performance_schema_max_file_instances                    | -1    |
| performance_schema_max_index_stat                        | -1    |
| performance_schema_max_memory_classes                    | 320   |
| performance_schema_max_metadata_locks                    | -1    |
| performance_schema_max_mutex_classes                     | 200   |
| performance_schema_max_mutex_instances                   | -1    |
| performance_schema_max_prepared_statements_instances     | -1    |
| performance_schema_max_program_instances                 | -1    |
| performance_schema_max_rwlock_classes                    | 40    |
| performance_schema_max_rwlock_instances                  | -1    |
| performance_schema_max_socket_classes                    | 10    |
| performance_schema_max_socket_instances                  | -1    |
| performance_schema_max_sql_text_length                   | 1024  |
| performance_schema_max_stage_classes                     | 150   |
| performance_schema_max_statement_classes                 | 192   |
| performance_schema_max_statement_stack                   | 10    |
| performance_schema_max_table_handles                     | -1    |
| performance_schema_max_table_instances                   | -1    |
| performance_schema_max_table_lock_stat                   | -1    |
| performance_schema_max_thread_classes                    | 50    |
| performance_schema_max_thread_instances                  | -1    |
| performance_schema_session_connect_attrs_size            | 512   |
| performance_schema_setup_actors_size                     | -1    |
| performance_schema_setup_objects_size                    | -1    |
| performance_schema_users_size                            | -1    |
+----------------------------------------------------------+-------+

Системные переменные Performance Schema могут быть установлены при запуске сервера в командной строке или в файлах опции, и многие могут быть установлены во времени выполнения. См. раздел 23.10.

Performance Schema автоматически измеряет значения нескольких из ее параметров при запуске сервера, если они не установлены явно. Для получения дополнительной информации см. раздел 23.2.2 .

У системных переменных Performance Schema есть следующие значения:

  • performance_schema

    Формат командной строки --performance_schema=#
    Системная Имя performance_schema
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип boolean
    Значение по умолчанию ON

    Значение этой переменной ON или OFF, чтобы указать, включена ли Performance Schema. По умолчанию значение ON. При запуске сервера Вы можете определить эту переменную без значения, со значением ON (или 1), чтобы включить или со значением OFF (или 0), чтобы выключить.

    Даже когда Performance Schema отключена, она продолжает заполнять таблицы populate the global_variables, session_variables, global_status и session_status. Это происходит по мере необходимости, чтобы разрешить результаты для SHOW VARIABLES и SHOW STATUS, которые будут оттянуты из тех таблиц, в зависимости от установки переменной show_compatibiliy_56.

  • performance_schema_accounts_size

    Формат командной строки --performance_schema_accounts_size=#
    Системная Имя performance_schema_accounts_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)
    Минимум -1 (autoscaled)
    Максимум 1048576

    Число строк в accounts . Если эта переменная 0, Performance Schema не поддерживает статистику соединения в accounts или информацию о переменных состояния в status_by_account.

  • performance_schema_digests_size

    Формат командной строки --performance_schema_digests_size=#
    Системная Имя performance_schema_digests_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autosized)
    Минимум -1
    Максимум 1048576

    Максимальное количество строк в таблице events_statements_summary_by_digest. Если этот максимум превышен таким образом, что обзор не может быть инструментован, Performance Schema постепенно увеличивает переменную Performance_schema_digest_lost.

  • performance_schema_error_size

    Формат командной строки --performance_schema_error_size
    Системная Имя performance_schema_error_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию number of server error codes
    Минимум 0
    Максимум 1048576

    Число инструментованных кодов ошибки сервера. Значение по умолчанию: фактическое число кодов ошибки сервера. Хотя значение может быть установлено от 0 до максимума, намеченное использование должно установить его в любое значение по умолчанию (чтобы инструментовать все ошибки) или 0 (чтобы не инструментовать ошибки).

    Информация об ошибке соединена в сводных таблицах, см. раздел 23.9.15.10. Если происходит ошибка, которая не инструментована, информация для возникновения соединена к строке NULL в каждой сводной таблице, то есть, к строке с ERROR_NUMBER=0, ERROR_NAME=NULL и SQLSTATE=NULL.

  • performance_schema_events_stages_history_long_size

    Формат командной строки --performance_schema_events_stages_history_long_size=#
    Системная Имя performance_schema_events_stages_history_long_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autosized)

    Число строк в events_stages_history_long.

  • performance_schema_events_stages_history_size

    Формат командной строки --performance_schema_events_stages_history_size=#
    Системная Имя performance_schema_events_stages_history_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autosized)

    Число строк на поток в events_stages_history.

  • performance_schema_events_statements_history_long_size

    Формат командной строки --performance_schema_events_statements_history_long_size=#
    Системная Имя performance_schema_events_statements_history_long_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autosized)

    Число строк в events_statements_history_long.

  • performance_schema_events_statements_history_size

    Формат командной строки --performance_schema_events_statements_history_size=#
    Системная Имя performance_schema_events_statements_history_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autosized)

    Число строк на поток в events_statements_history.

  • performance_schema_events_transactions_history_long_size

    Формат командной строки --performance_schema_events_transactions_history_long_size=#
    Системная Имя erformance_schema_events_transactions_history_long_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autosized)

    Число строк в events_transactions_history_long.

  • performance_schema_events_transactions_history_size

    Формат командной строки --performance_schema_events_transactions_history_size=#
    Системная Имя performance_schema_events_transactions_history_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autosized)

    Число строк на поток в events_transactions_history.

  • performance_schema_events_waits_history_long_size

    Формат командной строки --performance_schema_events_waits_history_long_size=#
    Системная Имя performance_schema_events_waits_history_long_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autosized)

    Число строк в events_waits_history_long.

  • performance_schema_events_waits_history_size

    Формат командной строки --performance_schema_events_waits_history_size=#
    Системная Имя performance_schema_events_waits_history_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autosized)

    Число строк на поток в events_waits_history .

  • performance_schema_hosts_size

    Формат командной строки --performance_schema_hosts_size=#
    Системная Имя performance_schema_hosts_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)
    Минимум -1 (autoscaled)
    Максимум 1048576

    Число строк в hosts. Если эта переменная 0, Performance Schema не поддерживает статистику соединения в hosts или информацию о переменных состояния в status_by_host.

  • performance_schema_max_cond_classes

    Формат командной строки --performance_schema_max_cond_classes=#
    Системная Имя performance_schema_max_cond_classes
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию 80

    Максимальное количество инструментованных условий.

  • performance_schema_max_cond_instances

    Формат командной строки --performance_schema_max_cond_instances=#
    Системная Имя performance_schema_max_cond_instances
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)

    Максимальное количество инструментованных объектов условия.

  • performance_schema_max_digest_length

    Формат командной строки --performance_schema_max_digest_length=#
    Системная Имя performance_schema_max_digest_length
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию 1024
    Минимум 0
    Максимум 1048576

    Максимальное количество байтов, доступных для вычислительных обзоров (см. раздел 23.7 ). Эта переменная походит на max_digest_length , но относится только к Performance Schema. Для получения дополнительной информации см. описание этой переменной в разделе 6.1.5.

  • performance_schema_max_file_classes

    Формат командной строки --performance_schema_max_file_classes=#
    Системная Имя performance_schema_max_file_classes
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию 80

    Максимальное количество инструментов файла.

  • performance_schema_max_file_handles

    Формат командной строки --performance_schema_max_file_handles=#
    Системная Имя performance_schema_max_file_handles
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию 32768

    Максимальное количество открытых объектов файла.

    Значение performance_schema_max_file_handles должно быть больше, чем значение open_files_limit : open_files_limit затрагивает максимальное количество открытых дескрипторов, которые сервер может поддержать, а performance_schema_max_file_handles указывает, сколько из этих дескрипторов может быть инструментовано.

  • performance_schema_max_file_instances

    Формат командной строки --performance_schema_max_file_instances=#
    Системная Имя performance_schema_max_file_instances
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)

    Максимальное количество инструментованных объектов файла.

  • performance_schema_max_index_stat

    Формат командной строки --performance_schema_max_index_stat=#
    Системная Имя performance_schema_max_index_stat
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autosized)

    Максимальное количество индексов, для которых Performance Schema поддерживает статистику. Если этот максимум превышен, статистика индексов потеряна, а Performance Schema постепенно увеличивает переменную Performance_schema_index_stat_lost. Значение по умолчанию задано, используя значение performance_schema_max_table_instances.

  • performance_schema_max_memory_classes

    Формат командной строки --performance_schema_max_memory_classes=#
    Системная Имя performance_schema_max_memory_classes
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию 320

    Максимальное количество инструментов памяти.

  • performance_schema_max_metadata_locks

    Формат командной строки --performance_schema_max_metadata_locks=#
    Системная Имя performance_schema_max_metadata_locks
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)

    Максимальное количество метаданных блокировки инструментов. Это значение управляет размером таблицы metadata_locks. Если этот максимум превышен таким образом, что блокировка метаданных не может быть инструментована, Performance Schema постепенно увеличивает Performance_schema_metadata_lock_lost.

  • performance_schema_max_mutex_classes

    Формат командной строки --performance_schema_max_mutex_classes=#
    Системная Имя performance_schema_max_mutex_classes
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию 200

    Максимальное количество инструментов mutex.

  • performance_schema_max_mutex_instances

    Формат командной строки --performance_schema_max_mutex_instances=#
    Системная Имя performance_schema_max_mutex_instances
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)

    Максимальное количество инструментованных объектов mutex.

  • performance_schema_max_prepared_statements_instances

    Формат командной строки --performance_schema_max_prepared_statements_instances=#
    Системная Имя performance_schema_max_prepared_statements_instances
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)

    Максимальное количество строк в таблице prepared_statements_instances. Если этот максимум превышен таким образом, что готовый запрос не может быть инструментован, Performance Schema постепенно увеличивает переменную Performance_schema_prepared_statements_lost. Значение по умолчанию этой переменной задано, основываясь на значении переменной max_prepared_stmt_count.

  • performance_schema_max_rwlock_classes

    Формат командной строки --performance_schema_max_rwlock_classes=#
    Системная Имя performance_schema_max_rwlock_classes
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию 40
    Допустимые значения Тип integer
    Значение по умолчанию 20

    Максимальное количество rwlock инструментов.

  • performance_schema_max_program_instances

    Формат командной строки --performance_schema_max_program_instances=#
    Системная Имя performance_schema_max_program_instances
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)

    Максимальное количество сохраненных программ, для которых Performance Schema поддерживает статистику. Если этот максимум превышен, Performance Schema постепенно увеличивает переменную Performance_schema_program_lost.

  • performance_schema_max_rwlock_instances

    Формат командной строки --performance_schema_max_rwlock_instances=#
    Системная Имя performance_schema_max_rwlock_instances
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)

    Максимальное количество инструментованных объектов rwlock.

  • performance_schema_max_socket_classes

    Формат командной строки --performance_schema_max_socket_classes=#
    Системная Имя performance_schema_max_socket_classes
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию 10

    Максимальное количество инструментов сокета.

  • performance_schema_max_socket_instances

    Формат командной строки --performance_schema_max_socket_instances=#
    Системная Имя performance_schema_max_socket_instances
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)

    Максимальное количество инструментованных объектов сокета.

  • performance_schema_max_sql_text_length

    Формат командной строки --performance_schema_max_sql_text_length=#
    Системная Имя performance_schema_max_sql_text_length
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию 1024
    Минимум 0
    Максимум 1048576

    Максимальное количество байтов, используемых, чтобы хранить запросы SQL в столбце SQL_TEXT таблиц событий events_statements_current, events_statements_history и events_statements_history_long. Любые байты сверх performance_schema_max_sql_text_length отказаны и не появляются в столбце SQL_TEXT. Запросы, отличающиеся только после этих начальных байтов, неразличимы в этом столбце.

    Уменьшение значения performance_schema_max_sql_text_length уменьшает использование памяти, но заставляет больше запросов становиться неразличимыми, если они отличаются только в конце. Увеличение значения увеличивает использование памяти, но разрешает более длинные запросы, которые отличаются.

  • performance_schema_max_stage_classes

    Формат командной строки --performance_schema_max_stage_classes=#
    Системная Имя performance_schema_max_stage_classes
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию 150

    Максимальное количество инструментов этапа.

  • performance_schema_max_statement_classes

    Формат командной строки --performance_schema_max_statement_classes=#
    Системная Имя performance_schema_max_statement_classes
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autosized)

    Максимальное количество инструментов запроса. Значение по умолчанию вычислено в сервере, основываясь на числе команд в протоколе клиент-сервер и числе типов запросов SQL, поддержанных сервером.

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

  • performance_schema_max_statement_stack

    Формат командной строки --performance_schema_max_statement_stack=#
    Системная Имя performance_schema_max_statement_stack
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию 10

    Максимальная глубина вложенных вызовов сохраненных программ, для которых Performance Schema поддерживает статистику. Когда этот максимум превышен, Performance Schema постепенно увеличивает переменную Performance_schema_nested_statement_lost для каждой выполненной сохраненной программы.

  • performance_schema_max_table_handles

    Формат командной строки --performance_schema_max_table_handles=#
    Системная Имя performance_schema_max_table_handles
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)

    Максимальное количество открытых табличных объектов. Это значение управляет размером таблицы table_handles. Если этот максимум превышен таким образом, что табличный дескриптор не может быть инструментован, Performance Schema постепенно увеличивает переменную Performance_schema_table_handles_lost.

  • performance_schema_max_table_instances

    Формат командной строки --performance_schema_max_table_instances=#
    Системная Имя performance_schema_max_table_instances
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)

    Максимальное количество инструментованных табличных объектов.

  • performance_schema_max_table_lock_stat

    Формат командной строки --performance_schema_max_table_lock_stat=#
    Системная Имя performance_schema_max_table_lock_stat
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autosized)

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

  • performance_schema_max_thread_classes

    Формат командной строки --performance_schema_max_thread_classes=#
    Системная Имя performance_schema_max_thread_classes
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию 50

    Максимальное количество инструментов потока.

  • performance_schema_max_thread_instances

    Формат командной строки --performance_schema_max_thread_instances=#
    Системная Имя performance_schema_max_thread_instances
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)

    Максимальное количество инструментованных объектов потока. Значение управляет размером таблицы threads . Если этот максимум превышен таким образом, что поток не может быть инструментован, Performance Schema постепенно увеличивает переменную Performance_schema_thread_instances_lost.

    Переменная max_connections затрагивает, сколько потоков может работать в сервере. performance_schema_max_thread_instances указывает, сколько из этих рабочих потоков может быть инструментовано.

    Таблицы variables_by_thread и status_by_thread содержат информацию только о потоках переднего плана. Если не все потоки будут инструментованы Performance Schema, то эта таблица пропустит некоторые строки. В этом случае переменная состояния Performance_schema_thread_instances_lost будет больше, чем ноль.

  • performance_schema_session_connect_attrs_size

    Формат командной строки --performance_schema_session_connect_attrs_size=#
    Системная Имя performance_schema_session_connect_attrs_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autosized)
    Минимум -1
    Максимум 1048576

    Количество предварительно выделенной памяти на поток, чтобы держать атрибуты соединения. Если совокупный размер данных о признаке соединения, посланных клиентом, больше чем это количество, Performance Schema усекает данные о признаке, увеличивая переменную Performance_schema_session_connect_attrs_lost и пишет сообщение в журнал ошибок, указывающее, что усечение произошло, если переменная log_warnings больше, чем ноль. Атрибут _truncated также добавлен к признакам сеанса со значением, указывающим, сколько байтов было потеряно, если у буфера признаков есть достаточное пространство. Это позволяет Performance Schema выставить информацию об усечении на соединение в таблицах атрибутов соединения. Эта информация может быть исследована, не имея необходимость проверять журнал ошибок.

    Значение по умолчанию performance_schema_session_connect_attrs_size задано при запуске сервера. Это значение может быть маленьким, так, если усечение происходит ( Performance_schema_session_connect_attrs_lost становится отличным от нуля), Вы можете хотеть установить performance_schema_session_connect_attrs_size явно к большему значению.

    Хотя максимум разрешенного значения performance_schema_session_connect_attrs_size составляет 1 МБ, эффективный максимум составляет 64 КБ, потому что сервер налагает предел в 64 КБ на совокупный размер данных о признаке соединения. Если клиент пытается послать больше чем 64 КБ данных о признаке, сервер отклоняет соединение. Для получения дополнительной информации см. раздел 23.9.9.

  • performance_schema_setup_actors_size

    Формат командной строки --performance_schema_setup_actors_size=#
    Системная Имя performance_schema_setup_actors_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)

    Число строк в таблице setup_actors.

  • performance_schema_setup_objects_size

    Формат командной строки --performance_schema_setup_objects_size=#
    Системная Имя performance_schema_setup_objects_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)

    Число строк в таблице setup_objects.

  • performance_schema_users_size

    Формат командной строки --performance_schema_users_size=#
    Системная Имя performance_schema_users_size
    Область действия Глобальная
    Динамическая Нет
    Допустимые значения Тип integer
    Значение по умолчанию -1 (autoscaled)
    Минимум -1 (autoscaled)
    Максимум 1048576

    Число строк в таблице users . Если эта переменная 0, Performance Schema не поддерживает статистику соединения в users или информацию о переменных состояния в status_by_user.

23.13. Переменные состояния Performance Schema

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

mysql> SHOW STATUS LIKE 'perf%';
+-------------------------------------------+-------+
| Variable_name                             | Value |
+-------------------------------------------+-------+
| Performance_schema_accounts_lost          | 0     |
| Performance_schema_cond_classes_lost      | 0     |
| Performance_schema_cond_instances_lost    | 0     |
| Performance_schema_file_classes_lost      | 0     |
| Performance_schema_file_handles_lost      | 0     |
| Performance_schema_file_instances_lost    | 0     |
| Performance_schema_hosts_lost             | 0     |
| Performance_schema_locker_lost            | 0     |
| Performance_schema_mutex_classes_lost     | 0     |
| Performance_schema_mutex_instances_lost   | 0     |
| Performance_schema_rwlock_classes_lost    | 0     |
| Performance_schema_rwlock_instances_lost  | 0     |
| Performance_schema_socket_classes_lost    | 0     |
| Performance_schema_socket_instances_lost  | 0     |
| Performance_schema_stage_classes_lost     | 0     |
| Performance_schema_statement_classes_lost | 0     |
| Performance_schema_table_handles_lost     | 0     |
| Performance_schema_table_instances_lost   | 0     |
| Performance_schema_thread_classes_lost    | 0     |
| Performance_schema_thread_instances_lost  | 0     |
| Performance_schema_users_lost             | 0     |
+-------------------------------------------+-------+

У переменных состояния Performance Schema есть следующие значения:

Для информации об использовании этих переменных, чтобы проверить статус Performance Schema, см. раздел 23.5.

23.14. Модель распределения памяти Performance Schema

Performance Schema использует эту модель распределения памяти:

  • Может выделить память при запуске сервера.

  • Может выделить дополнительную память во время работы сервера.
  • Никогда не освобождайте память во время работы сервера (хотя это могло бы быть переработано).
  • Освобождает всю память при завершении работы.

Результат состоит в том, чтобы ослабить ограничения памяти так, чтобы Performance Schema могла использоваться с меньшим количеством конфигурации, и уменьшить расход памяти так, чтобы потребление масштабировалось с загрузкой сервера. Используемая память зависит от загрузки, фактически замеченной, не оцененной загрузки или явно сконфигурированный.

Несколько измеряющих параметров Performance Schema автомасштабируются и не должны быть сконфигурированы явно, если Вы не хотите установить явный предел на распределение памяти:

performance_schema_accounts_size
performance_schema_hosts_size
performance_schema_max_cond_instances
performance_schema_max_file_instances
performance_schema_max_index_stat
performance_schema_max_metadata_locks
performance_schema_max_mutex_instances
performance_schema_max_prepared_statements_instances
performance_schema_max_program_instances
performance_schema_max_rwlock_instances
performance_schema_max_socket_instances
performance_schema_max_table_handles
performance_schema_max_table_instances
performance_schema_max_table_lock_stat
performance_schema_max_thread_instances
performance_schema_users_size

Для автомасштабируемого параметра конфигурация работает так:

  • С набором значений -1 (по умолчанию), автомасштабируется параметр:

    • Соответствующий внутренний буфер пуст первоначально, и никакая память не выделена.

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

  • С набором значений 0:

    • Соответствующий внутренний буфер пуст первоначально, и никакая память не выделена.

  • С набором значений N > 0:

    • Соответствующий внутренний буфер пуст первоначально, и никакая память не выделена.

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

Чтобы видеть, сколько памяти использует Performance Schema, проверьте инструменты, разработанные с этой целью. Performance Schema выделяет память внутренне и связывает каждый буфер со специализированным инструментом так, чтобы потребление памяти могло быть прослежено к отдельным буферам. Инструменты с приставкой memory/performance_schema/ покажут, сколько памяти выделено для этих внутренних буферов. Буферы глобальны для сервера, таким образом, инструменты выведены на экран только в таблице memory_summary_global_by_event_name, а не в других таблицах memory_summary_by_xxx_by_event_name.

Этот запрос показывает информацию, связанную с инструментами памяти:

SELECT * FROM memory_summary_global_by_event_name
         WHERE EVENT_NAME LIKE 'memory/performance_schema/%';

23.15. Performance Schema и плагины

Удаление плагина с UNINSTALL PLUGIN не затрагивает информацию, уже собранную для кода в этом плагине. Время на выполнение кода, в то время как плагин был загружен, все еще учтено, даже если плагин позже выгружен. Связанная информация о событии, включая совокупную информацию, остается читаемой в таблицах базы данных performance_schema. Для дополнительной информации об эффекте установки и удаления плагина см. раздел 23.5.

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

23.16. Применение Performance Schema, чтобы диагностировать проблемы

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

Следующий пример обеспечивает одну методологию, которую Вы можете использовать, чтобы проанализировать повторимую проблему, такую как исследование исполнительного узкого места. Чтобы начать, у Вас должен быть повторимый случай использования, где работу считают слишком медленной и нуждающейся в оптимизации, и Вы должны включить всю инструментовку (никакой предварительной фильтрации вообще).

  1. Выполните случай использования.

  2. Используя таблицы Performance Schema, проанализируйте первопричину исполнительной проблемы. Этот анализ положится в большой степени на постфильтрацию.
  3. Для проблемных областей, которые исключены, отключите соответствующие инструменты. Например, если анализ показывает, что проблема не связана с вводом/выводом файла в особом механизме хранения, отключите инструменты ввода/вывода файла для этого механизма. Затем усеките историю и сводные таблицы, чтобы удалить ранее собранные события.
  4. Повторите процесс в шаге 1.

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

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

  5. Как только первопричина исполнительного узкого места идентифицирована, примите соответствующие меры по ликвидации последствий, такие как:

    • Настройте параметры сервера (размеры кэша, памяти и т.д.).

    • Настройте запрос по-другому.
    • Настройте схему базы данных (таблицы, индексы и т.д.).
    • Настройте код (это относится только к механизму хранения или разработчикам сервера).

  6. Начните снова с шага 1, чтобы видеть эффекты изменений.

Столбцы mutex_instances.LOCKED_BY_THREAD_ID и rwlock_instances.WRITE_LOCKED_BY_THREAD_ID чрезвычайно важны для исследования исполнительных узких мест или тупиков. Это сделано возможным инструментовкой Performance Schema следующим образом:

  1. Предположите, что поток 1 застревает, ожидая mutex.

  2. Вы можете определить то, чего ждет поток:
    SELECT * FROM events_waits_current
             WHERE THREAD_ID = thread_1;
    

    Скажите, что результат запроса идентифицирует, что поток ждет mutex A, найденный в events_waits_current.OBJECT_INSTANCE_BEGIN.

  3. Вы можете определить, какой поток держит mutex A:
    SELECT * FROM mutex_instances
             WHERE OBJECT_INSTANCE_BEGIN = mutex_A;
    

    Скажите, что результат запроса идентифицирует, что это поток 2, который держит mutex A, как найдено в mutex_instances.LOCKED_BY_THREAD_ID.

  4. Вы можете видеть, что делает поток 2:
    SELECT * FROM events_waits_current
             WHERE THREAD_ID = thread_2;
    

23.16.1. Профилирование запроса, используя Performance Schema

Следующий пример демонстрирует, как использовать события запросов Performance Schema и события этапа, чтобы получить данные, сопоставимые с профилированием информации, предоставленной SHOW PROFILES и SHOW PROFILE.

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

Performance Schema выводит на экран информацию о таймере событий в пикосекундах, чтобы нормализовать данные о синхронизации к стандартному модулю. В следующем примере TIMER_WAIT разделены на 1000000000000, чтобы показать данные в модулях секунд. Значения являются также усеченными к 6 десятичным разрядам, чтобы вывести на экран данные в том же самом формате, как SHOW PROFILES и SHOW PROFILE.

  1. Ограничьте набор исторических событий пользователю, который выполняет запрос. По умолчанию setup_actors сконфигурирован, чтобы позволить контролировать набор исторических событий для всех потоков переднего плана:

    mysql> SELECT * FROM setup_actors;
    +------+------+------+---------+---------+
    | HOST | USER | ROLE | ENABLED | HISTORY |
    +------+------+------+---------+---------+
    | %    | %    | %    | YES     | YES     |
    +------+------+------+---------+---------+
    

    Обновите строку значения по умолчанию в setup_actors, чтобы отключить сбор исторических событий для всех потоков переднего плана, и вставить новую строку, которая позволяет контролировать и собирать исторические события для пользователя, который выполняет запрос:

    mysql> UPDATE performance_schema.setup_actors
                     SET ENABLED = 'NO', HISTORY = 'NO'
                     WHERE HOST = '%' AND USER = '%';
    
    mysql> INSERT INTO performance_schema.setup_actors(HOST,USER,ROLE,
                     ENABLED,HISTORY)
                     VALUES('localhost','test_user','%','YES','YES');
    

    Данные в setup_actors должны теперь казаться похожими на:

    mysql> SELECT * FROM performance_schema.setup_actors;
    +-----------+-----------+------+---------+---------+
    | HOST      | USER      | ROLE | ENABLED | HISTORY |
    +-----------+-----------+------+---------+---------+
    | %         | %         | %    | NO      | NO      |
    | localhost | test_user | %    | YES     | YES     |
    +-----------+-----------+------+---------+---------+
    
  2. Гарантируйте, что запрос и инструментовка включены, обновляя setup_instruments . Некоторые инструменты могут уже быть включены по умолчанию.
    mysql> UPDATE performance_schema.setup_instruments SET ENABLED = 'YES',
                     TIMED = 'YES' WHERE NAME LIKE '%statement/%';
    mysql> UPDATE performance_schema.setup_instruments SET ENABLED = 'YES',
                     TIMED = 'YES' WHERE NAME LIKE '%stage/%';
    
  3. Гарантируйте, что потребители events_statements_* и events_stages_* включены. Некоторые потребители уже включены по умолчанию.
    mysql> UPDATE performance_schema.setup_consumers SET ENABLED = 'YES'
                     WHERE NAME LIKE '%events_statements_%';
    mysql> UPDATE performance_schema.setup_consumers SET ENABLED = 'YES'
                     WHERE NAME LIKE '%events_stages_%';
    
  4. Под учетной записью пользователя выполните запрос, который Вы хотите профилировать. Например:
    mysql> SELECT * FROM employees.employees WHERE emp_no = 10001;
    +--------+------------+------------+-----------+--------+------------+
    | emp_no | birth_date | first_name | last_name | gender | hire_date  |
    +--------+------------+------------+-----------+--------+------------+
    |  10001 | 1953-09-02 | Georgi     | Facello   | M      | 1986-06-26 |
    +--------+------------+------------+-----------+--------+------------+
    
  5. Идентифицируйте EVENT_ID из запроса, запрашивая таблицу events_statements_history_long. Этот шаг подобен выполнению SHOW PROFILES, чтобы идентифицировать Query_ID. Следующий запрос производит вывод, подобный SHOW PROFILES:
    mysql> SELECT EVENT_ID, TRUNCATE(TIMER_WAIT/1000000000000,6)
                     as Duration, SQL_TEXT
                     FROM performance_schema.events_statements_history_long
                     WHERE SQL_TEXT like '%10001%';
    +----------+----------+--------------------------------------------------------+
    | event_id | duration | sql_text                                               |
    +----------+----------+--------------------------------------------------------+
    | 31       | 0.028310 | SELECT * FROM employees.employees WHERE emp_no = 10001 |
    +----------+----------+--------------------------------------------------------+
    
  6. Запросите таблицу events_stages_history_long, чтобы получить события этапа запроса. Этапы соединены с запросами, используя вложение событий. У каждого отчета этапа событий есть столбец NESTING_EVENT_ID, который содержит EVENT_ID из родительского запроса.
    mysql> SELECT event_name AS Stage, TRUNCATE(TIMER_WAIT/1000000000000,6)
                     AS Duration
                     FROM performance_schema.events_stages_history_long
                     WHERE NESTING_EVENT_ID=31;
    +--------------------------------+----------+
    | Stage                          | Duration |
    +--------------------------------+----------+
    | stage/sql/starting             | 0.000080 |
    | stage/sql/checking permissions | 0.000005 |
    | stage/sql/Opening tables       | 0.027759 |
    | stage/sql/init                 | 0.000052 |
    | stage/sql/System lock          | 0.000009 |
    | stage/sql/optimizing           | 0.000006 |
    | stage/sql/statistics           | 0.000082 |
    | stage/sql/preparing            | 0.000008 |
    | stage/sql/executing            | 0.000000 |
    | stage/sql/Sending data         | 0.000017 |
    | stage/sql/end                  | 0.000001 |
    | stage/sql/query end            | 0.000004 |
    | stage/sql/closing tables       | 0.000006 |
    | stage/sql/freeing items        | 0.000272 |
    | stage/sql/cleaning up          | 0.000001 |
    +--------------------------------+----------+
    

23.17. Переход к таблицам переменных системы и состояния Performance Schema

INFORMATION_SCHEMA имеет таблицы, которые содержат информацию о переменных состояния (см. разделы 22.10 и 22.9). Performance Schema также содержит таблицы переменных системы и состояния (см. разделы 23.9.13 и 23.9.14). Таблицы Performance Schema предназначены, чтобы заменить INFORMATION_SCHEMA, которые устарели с MySQL 5.7.6 и будут удалены в будущем выпуске MySQL.

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

MySQL 5.6

В MySQL 5.6 информация о переменных состояния доступна через команду SHOW:

SHOW VARIABLES
SHOW STATUS

И через таблицы INFORMATION_SCHEMA:

INFORMATION_SCHEMA.GLOBAL_VARIABLES
INFORMATION_SCHEMA.SESSION_VARIABLES
INFORMATION_SCHEMA.GLOBAL_STATUS
INFORMATION_SCHEMA.SESSION_STATUS

MySQL 5.7

С MySQL 5.7.6 Performance Schema включает эти таблицы как новые источники информации о переменных состояния:

performance_schema.global_variables
performance_schema.session_variables
performance_schema.variables_by_thread
performance_schema.global_status
performance_schema.session_status
performance_schema.status_by_thread
performance_schema.status_by_account
performance_schema.status_by_host
performance_schema.status_by_user

MySQL 5.7.6 также добавляет системную переменную show_compatibility_56 , чтобы управлять, как сервер делает доступной информацию о переменных состояния.

Когда show_compatibility_56 ON, совместимость с MySQL 5.6 включена. Более старая система и источники переменных состояния (запросы SHOW, таблицы INFORMATION_SCHEMA) доступны с семантикой, идентичной MySQL 5.6. Приложения должны работать без изменений кода и должен видеть те же самые имена переменных и значения, как в MySQL 5.6. Предупреждения происходят при этих обстоятельствах:

  • Предупреждение поднято при выборе из таблиц INFORMATION_SCHEMA.

Когда show_compatibility_56 OFF, совместимость с MySQL 5.6 отключена и несколько результатов изменены. Приложения должны быть пересмотрены следующим образом, чтобы работать должным образом:

  • Выбор из таблицы INFORMATION_SCHEMA производит ошибку. Приложения с доступом к INFORMATION_SCHEMA должны быть пересмотрены, чтобы использовать соответствующие таблицы Performance Schema.

    До MySQL 5.7.9 выбор из INFORMATION_SCHEMA производит пустой набор результатов плюс предупреждение об устаревании. Это не было достаточным уведомлением, чтобы сигнализировать о потребности мигрировать к соответствующей системе Performance Schema, если show_compatibility_56=OFF. Производство ошибки в MySQL 5.7.9 и выше делает более очевидным, что приложение работает при условиях, которые требуют модификации, так же как где проблема заключается.

  • Вывод для SHOW произведен, используя основные таблицы Performance Schema. Приложения, написанные, чтобы использовать эти запросы, могут все еще использовать их.
  • Эти переменные состояния Slave_xxx становятся недоступными через SHOW STATUS :
    Slave_heartbeat_period
    Slave_last_heartbeat
    Slave_received_heartbeats
    Slave_retried_transactions
    Slave_running
    

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

Миграция и привилегии

Первоначально, с введением Performance Schema в MySQL 5.7.6, доступ к тем таблицам требовал привилегии SELECT , так же, как для других таблиц Performance Schema. Однако, у этого было последствие, когда show_compatibility_56=OFF, SHOW VARIABLES и SHOW STATUS также потребовали привилегию SELECT: с отключенной совместимостью вывод для тех запросов, был взят из таблиц Performance Schema global_variables, session_variables, global_status и session_status.

Эти таблицы Performance Schema доступны без привилегии SELECT. Следовательно, SHOW VARIABLES и SHOW STATUS не требуют привилегий на основных таблицах Performance Schema, из которых их вывод произведен, когда show_compatibility_56=OFF.

Вне MySQL 5.7

В будущем выпуске MySQL переменные таблицы INFORMATION_SCHEMA и переменная show_compatibility_56 будут удалены, и вывод SHOW всегда будет основан на основных таблицах Performance Schema.

Приложения, которые были пересмотрены, чтобы работать в MySQL 5.7, когда show_compatibility_56=OFF, должны работать без дальнейших изменений, за исключением того, что не будет возможно проверить или установить show_compatibility_56 потому, что это не будет существовать.

Поиск

 

Найди своих коллег!

Вы можете направить письмо администратору этой странички, Алексею Паутову. mailto:alexey.v.pautov@mail.ru