Глава 23. MySQL Performance Schema

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

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. Первые несколько столбцов предоставляют следующую информацию:

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

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 одно из этих значений:

Каждая опция --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 одно из этих значений:

Например, чтобы включить потребителя 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 предоставляют информацию о таймере:

Каждая строка таймера в 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          |
+-------------+-----------------+------------------+----------------+

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

Чтобы видеть, который таймеры работают или изменить таймеры, получите доступ к таблице 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() может взять сотни циклов, что является недопустимыми издержками для того, что может произойти тысячи или миллионы раз в секунду.

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

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

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

События, которые еще не завершились, имеют значение 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

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

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

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

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

Предварительная фильтрация сделана 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.

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 проверяет строки в этом порядке:

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

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

Для хранимых объектов программы 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:

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

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

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

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

Таблица 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

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

Для потоков переднего плана (следующих из соединений клиента), начальные значения столбцов 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 не использован):

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

Столбцы 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 для потока нового соединения следующим образом:

Модификации 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 имеют иерархию. Следующие принципы применяются:

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

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

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

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

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

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

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

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

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

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

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

Этот потребитель требует 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      |
...
+----------------------------------+---------+

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

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

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

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

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

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 и 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      |
...
+----------------------------------+---------+

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

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

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     |
...
+----------------------------------+---------+

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

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

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     |
...
+----------------------------------+---------+

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

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   |
+--------------------------------------+---------+-------+

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

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 относится к инструменту. Для части приставки инструментальных имен верхний уровень указывает на тип инструмента.

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

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

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

Инструмент 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 .

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

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

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

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

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

Сервер выделяет 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 является слишком маленьким, ни о какой ошибке не сообщают в журнале ошибок и нет никакого отказа во время выполнения. Однако, контент таблиц в 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 запрос вовлекает эти компоненты:

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

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

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, а не удалить строки. Это позволяет очистить собранные значения. Это могло бы быть полезно, например, после того, как Вы произвели изменение конфигурации во время выполнения. Исключения к этому поведению усечения отмечены в отдельных разделах сводной таблицы.

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

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

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

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, чтобы произвести многократные одновременные изменения конфигурации.

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

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 есть эти столбцы:

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

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 есть эти столбцы:

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

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 есть эти столбцы:

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

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 есть эти столбцы:

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

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 есть эти столбцы:

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

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 есть эти столбцы:

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

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

23.9.3.2. Таблица file_instances

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

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

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

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

23.9.3.3. Таблица mutex_instances

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

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

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

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

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

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

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

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

23.9.3.4. Таблица rwlock_instances

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

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

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

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

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

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

Есть ограничение: 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 есть эти столбцы:

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

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

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

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 есть эти столбцы:

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

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 содержат два столбца, которые, вместе взятые, обеспечивают индикатор хода выполнения этапа для каждой строки:

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

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

Инструмент 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 есть эти столбцы:

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

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:

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

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

Детали для запроса первоначально неизвестны и 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 есть эти столбцы:

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

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 обеспечивает инструментовку для готовых запросов, для которых есть два протокола:

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 следующим образом:

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

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

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 определяет операционные границы аналогично серверу. Запуск и конец операционного случая близко соответствуют соответствующим изменениям состояния в сервере:

Есть тонкие значения к этому подходу:

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

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

Операционная инструментовка

Три признака определяют транзакции:

Чтобы уменьшить сложность операционной инструментовки и гарантировать, что собранные операционные данные обеспечивают полные, значащие результаты, все транзакции инструментованы независимо от режима доступа, уровня изоляции или режима 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 есть эти столбцы:

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

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 обеспечивает статистику об этих соединениях, отслеживая их для учетной записи (комбинация пользователя и узла), а также отдельно для имени пользователя и имени хоста, используя эти таблицы:

Значение 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 отслеживает соединения следующим образом:

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

Когда клиент разъединяется, Performance Schema уменьшает столбец CURRENT_CONNECTIONS в строке и не меняет столбец TOTAL_CONNECTIONS.

TRUNCATE TABLE позволен на таблицах соединения. Это имеет эффекты:

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.

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

23.9.8.2. Таблица hosts

Таблица hosts содержит строку для каждого узла, с которого клиенты соединились с сервером MySQL. Для каждого имени хоста таблица считает текущее и общее количество соединений. Табличный размер задан при запуске сервера. Чтобы установить табличный размер явно, установите системную переменную performance_schema_hosts_size при запуске сервера. Чтобы отключить статистику учетной записи, установите эту переменную в 0.

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

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

23.9.8.3. Таблица users

Таблица users содержит строку для каждого пользователя, который соединился с сервером MySQL. Для каждого имени пользователя таблица считает текущее и общее количество соединений. Табличный размер задан при запуске сервера. Чтобы установить табличный размер явно, установите переменную performance_schema_users_size при запуске сервера. Чтобы отключить пользовательскую статистику, установите эту переменную в 0.

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

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

23.9.9. Таблицы атрибутов соединения Performance Schema

Приложения могут предоставить пары ключ/значение как атрибуты соединения для передачи серверу во время соединения. Для C API определите набор признака, используя функции mysql_options() и mysql_options4(). Другие MySQL Connector могут обеспечить свои собственные методы определения.

Эти таблицы выставляют информацию атрибута:

Названия атрибутов, которые начинаются с подчеркивания (_), сохранены для внутреннего пользования и не должен быть созданы приложениями. Это соглашение разрешает новым признакам быть введенными MySQL, не сталкиваясь с признаками приложения.

Набор признаков соединения, видимых в данном соединении, изменяется в зависимости от Вашей платформы и MySQL Connector, которым установили соединение.

Библиотека клиента libmysqlclient (обеспечена в MySQL и MySQL Connector/C) устанавливает эти признаки:

Прочие MySQL Connector могут определить свои собственные признаки соединения.

MySQL Connector/J определяет эти признаки:

MySQL Connector/Net определяет эти признаки:

PHP определяет признаки, которые зависят от того, как он был собран:

Много программ клиента MySQL устанавливают признак program_name со значением, равным имени клиента. Например, mysqladmin и mysqldump устанавливают program_name в mysqladmin и mysqldump, соответственно.

Некоторые программы клиента MySQL определяют дополнительные признаки:

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

Для соединений, начатых, используя C API, библиотека libmysqlclient налагает предел 64 КБ на совокупный размер данных о признаке соединения по стороне клиента: вызовы mysql_options(), которые превышают этот предел, производят ошибку CR_INVALID_PARAMETER_NO. Другие MySQL Connector могут наложить свои собственные клиентские пределы на то, сколько данных о признаке соединения может быть передано серверу.

На стороне сервера данные о признаке соединения проверяются так:

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 есть эти столбцы:

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

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 есть эти столбцы:

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

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

23.9.10. Таблицы пользовательских переменных Performance Schema

Performance Schema обеспечивает таблицу user_variables_by_thread, которая выставляет определяемые пользователем переменные. Это переменные, определенные в пределах определенного сеанса, и включают символ @, предшествующий имени.

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

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

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

23.9.11. Таблицы репликации Performance Schema

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

Описание таблиц репликации

Performance Schema обеспечивает несколько связанных таблиц:

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

Остаток этого введения в таблицы описывает, как Performance Schema заполняет их, и которые области от SHOW SLAVE STATUS не представлены в таблицах.

Жизненный цикл таблиц

Performance Schema заполняет таблицы следующим образом:

Информация SHOW SLAVE STATUS не в таблицах репликации

Информация в таблицах Performance Schema несколько отличается от информации, доступной от SHOW SLAVE STATUS потому? что таблицы ориентируются на использование глобальных операционных идентификаторов (GTID), а не имен файла и позиций, и они представляют серверные значения UUID, а не значения ID сервера. Из-за этих различий, несколько столбцов SHOW SLAVE STATUS не сохранены в Performance Schema или представлены иным путем:

Переменные состояния, перемещенные в таблицы

Начиная с 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 есть эти столбцы:

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

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 есть эти столбцы:

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

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 есть эти столбцы:

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

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 есть эти столбцы:

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

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 есть эти столбцы:

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

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 есть эти столбцы:

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

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 имеет следующие столбцы:

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

23.9.11.8. Таблица replication_group_member_stats

Эта таблица показывает статистическую информацию для членов группы.

У replication_group_member_stats есть следующие столбцы:

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

23.9.12. Таблицы блокировки Performance Schema

Performance Schema выставляет информацию о блокировке через эти таблицы:

Следующие разделы описывают эти таблицы более подробно.

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 есть эти столбцы:

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

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 есть эти столбцы:

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

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, чтобы указать на состояние каждой блокировки:

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

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

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 есть эти столбцы:

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

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:

Таблицы переменной сеанса ( session_variables, variables_by_thread) содержат информацию только для активных сеансов, не законченных сеансов.

TRUNCATE TABLE не допускается для системных таблиц переменных Performance Schema.

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

У global_variables и session_variables есть индексы:

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

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

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

23.9.13.1. Таблица variables_info

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

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

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:

23.9.14. Таблицы состояния переменных Performance Schema

Значение переменной show_compatibility_56 затрагивает информацию, доступную из таблиц, описанных здесь. Для деталей см. описание этой переменной в разделе 6.1.5.

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

Есть также сводные таблицы, которые предоставляют информацию о переменных состояния, связанные учетной записью, именем хоста и именем пользователя. См. раздел 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 есть эти столбцы:

У global_status и session_status есть индексы:

status_by_thread содержит состояние каждого активного потока. У нее есть эти столбцы:

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

status_by_thread содержит информацию о переменной состояния только о потоках переднего плана. Если переменная performance_schema_max_thread_instances не автомасштабируется (установлена в -1), и максимальное разрешенное число инструментованных объектов потока не больше, чем число фоновых потоков, таблица будет пуста.

Performance Schema поддерживает TRUNCATE TABLE для таблиц переменных состояния следующим образом:

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

23.9.15. Сводные таблицы Performance Schema

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

Резюме событий ожидания:

Резюме этапа:

Резюме запросов:

Операционные резюме:

Резюме ожидания объекта:

Резюме ввода/вывода файла:

Табличный ввод / вывод и ожидание блокировки:

Резюме сокета:

Резюме памяти:

Резюме ошибок:

Резюме переменных состояния:

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

Сводные таблицы могут быть усечены с 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 .

У сводной таблицы событий есть эти сводные столбцы, содержащие соединенные значения:

Сводные таблицы событий имеют индексы:

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 .

У каждой сводной таблицы этапа есть эти сводные столбцы, содержащие соединенные значения: 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_digest есть эти дополнительные сводные столбцы:

У events_statements_summary_by_program есть эти дополнительные сводные столбцы:

У prepared_statements_instances есть эти дополнительные сводные столбцы:

Сводные таблицы запросы имеют индексы:

TRUNCATE TABLE позволен для сводных таблиц запросов. Это имеет эффекты:

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

Правила агрегации обзоров запросов

Если потребитель включен statement_digest, агрегация в events_statements_summary_by_digest происходит следующим образом, когда запрос завершается. Агрегация основана на значении DIGEST, вычисленном для запроса.

Строка с DIGEST = NULL поддержана, потому что у таблиц Performance Schema есть максимальный размер из-за ограничений памяти. Строка DIGEST = NULL разрешает обзоры, которые не соответствуют другим строкам, которые будут посчитаны, даже если сводная таблица полна. Эта строка помогает Вам оценить, является ли резюме обзора представительным:

Поведение инструментовки сохраненной программы

Для типов сохраненных программ, для которых инструментовка включена в 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 .

У каждой операционной сводной таблицы есть эти сводные столбцы, содержащие соединенные значения:

Операционные сводные таблицы имеют индексы:

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 есть эти индексы:

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 .

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

Сводные таблицы ввода/вывода файла имеют индексы:

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

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

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, который соответствует названию индекса, который использовался, когда случай ожидания табличного ввода/вывода был зарегистрирован:

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

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. Группировка по таблице.

Эта таблица содержит информацию о внутренних и внешних блокировках:

У table_lock_waits_summary_by_table есть эти столбцы группировки, чтобы указать как табличные события объединяются: OBJECT_TYPE, OBJECT_SCHEMA и OBJECT_NAME. У этих столбцов есть то же самое значение, как в events_waits_current . Они идентифицируют таблицу, к которой применяется строка.

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

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

TRUNCATE TABLE разрешен для сводных таблиц блокировки. Это сбрасывает сводные столбцы к нолю вместо того, чтобы удалить строки.

23.9.15.8. Сводные таблицы сокета

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

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

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

У каждой сводной таблицы сокета есть эти сводные столбцы, содержащие соединенные значения:

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 .

У каждой сводной таблицы памяти есть эти сводные столбцы, содержащие соединенные значения:

Сводные таблицы памяти имеют индексы:

TRUNCATE TABLE позволен на сводных таблицах памяти. Это имеет эффекты:

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

Когда инструментованный блок памяти освобожден, 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 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

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

У каждой сводной таблицы есть эти сводные столбцы, содержащие соединенные значения:

Строка NULL в каждой сводной таблице нужна для совокупной статистики для всех ошибок, которые лежат вне диапазона инструментованных ошибок. Например, если ошибки MySQL Server находятся в диапазоне от M до N и ошибка поднята с номером Q не в этом диапазоне, ошибка показана в строке NULL. Это строка с ERROR_NUMBER=0, ERROR_NAME=NULL и SQLSTATE=NULL.

Сводные таблицы ошибок имеют индексы:

TRUNCATE TABLE позволен на сводных таблицах ошибок. Это имеет эффекты:

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

23.9.15.11. Сводные таблицы переменных состояния

Значение системной переменной show_compatibility_56 затрагивает информацию, доступную из таблиц, описанных здесь. Для деталей см. описание этой переменной в разделе 6.1.5.

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

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

Сводные таблицы переменной состояния имеют индексы:

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

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

Учетная запись, узел и пользовательская статистика не собраны, если переменные performance_schema_accounts_size, performance_schema_hosts_size и performance_schema_users_size, соответственно, установлены в 0.

Performance Schema поддерживает TRUNCATE TABLE для сводных таблиц переменных состояния следующим образом, во всех случаях состояние для активных сеансов не затронуто:

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

23.9.16. Прочие таблицы Performance Schema

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

23.9.16.1. Таблица host_cache

Таблица host_cache обеспечивает доступ к содержанию кэша узла, который содержит имя хоста клиента и информацию об IP-адресе и используется, чтобы избежать поисков DNS (см. раздел 9.12.4.2). host_cache выставляет содержание кэша узла так, чтобы это могло быть исследовано, используя SELECT. Performance Schema должна быть включена, или эта таблица пуста.

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

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

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 есть эти столбцы:

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 отличается от использования других двух источников:

По этим причинам, DBA выполняет контроль сервера, используя INFORMATION_SCHEMA.PROCESSLIST или SHOW PROCESSLIST и может хотеть контролировать, используя вместо этого threads.

Для INFORMATION_SCHEMA.PROCESSLIST и SHOW PROCESSLIST информацию о потоках для других пользователей показывают, только если текущий пользователь имеет привилегию PROCESS. Это не так для таблицы threads : все строки показывают любому пользователю, который имеет привилегию SELECT для таблицы. Пользователям, которые не должны быть в состоянии видеть потоки для других пользователей, нельзя давать эту привилегию.

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

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

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 .

Следующие элементы конфигурируют отдельных потребителей:

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 есть следующие значения:

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

Для автомасштабируемого параметра конфигурация работает так:

Чтобы видеть, сколько памяти использует 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. Предупреждения происходят при этих обстоятельствах:

Когда show_compatibility_56 OFF, совместимость с MySQL 5.6 отключена и несколько результатов изменены. Приложения должны быть пересмотрены следующим образом, чтобы работать должным образом:

Миграция и привилегии

Первоначально, с введением 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 потому, что это не будет существовать.