MySQL Performance Schema особенность контроля выполнения MySQL Server на низком уровне. У Performance Schema есть эти характеристики:
Performance Schema обеспечивает способ осмотреть внутреннее
выполнение сервера во времени выполнения. Это осуществлено, используя
механизм хранения PERFORMANCE_SCHEMA
и
базу данных performance_schema
. Performance Schema
сосредотачивается прежде всего на характеристиках. Это отличается от
INFORMATION_SCHEMA
, которая служит для просмотра метаданных.
PERFORMANCE_SCHEMA
собирает данные событий, используя точки инструментовки
в исходном коде сервера.performance_schema
. Эти таблицы могут быть запрошены, используя
SELECT
как другие таблицы.performance_schema
через запросы SQL. Конфигурация немедленно изменяет сбор данных.performance_schema
это
представления или временные таблицы, которые не используют постоянного
хранения на диске.Некоторые ограничения могут применяться: типы таймеров могут изменяться для платформы. Инструменты, которые относятся к механизмам хранения, не могут быть осуществлены для всех механизмов хранения. Инструментовка каждого имеющего отношение к третьей стороне механизма ответственность автора механизма. См. также раздел C.8.
Performance Schema предназначена, чтобы обеспечить доступ к полезной информации о выполнении сервера, оказывая минимальное влияние на работу сервера. Выполнение следует за этими целями проекта:
Активирование Performance Schema не вызывает изменений в поведении
сервера. Например, это не вызывает поток, намечающий измениться, и это не
меняет план выполнения запроса (как показано
EXPLAIN
).
MySQL sys
schema ряд объектов, который обеспечивает удобный
доступ к данным, собранным Performance Schema. sys
schema
установлена по умолчанию. Для инструкций см. раздел 24.
Этот раздел кратко начинает Performance Schema с примеров, которые показывают, как использовать это. Для дополнительных примеров см. раздел 23.16.
Чтобы Performance Schema была доступна, она должна быть сконфигурирована,
когда MySQL был создан. Вы можете проверить обстоит ли дело так, проверяя
вывод сервера. Если Performance Schema доступна, то вывод упомянет несколько
переменных с именами, которые начинаются с performance_schema
:
shell> mysqld --verbose --help ... --performance_schema Enable the performance schema. --performance_schema_events_waits_history_long_size=# Number of rows in events_waits_history_long. ...
Если такие переменные не появляются в выводе, Ваш сервер не был создан, чтобы поддерживать Performance Schema. В этом случае см. раздел 23.2.
Предполагая, что Performance Schema доступна, она включена по умолчанию.
Чтобы включить или отключить это явно, запустите сервер с соответствующим
значением переменной
performance_schema
. Например, используйте эти строки в Вашем
файле my.cnf
:
[mysqld] performance_schema=ON
Когда сервер запускается, он видит
performance_schema
и попытается инициализировать Performance Schema.
Чтобы проверить успешную инициализацию, используйте этот запрос:
mysql> SHOW VARIABLES LIKE 'performance_schema'; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | performance_schema | ON | +--------------------+-------+
Значение ON
указывает, что Performance Schema
инициализированная успешно и готова к употреблению. Значение OFF
указывает, что некоторая ошибка произошла. Проверьте журнал ошибок сервера на
информацию о том, что пошло не так, как надо.
Performance Schema осуществлена как механизм хранения. Если этот механизм
доступен (это Вы должны были уже проверить ранее), Вы должны видеть, что он
перечислен со значением YES
столбца SUPPORT
таблицы
INFORMATION_SCHEMA.ENGINES
или вывода SHOW ENGINES
:
mysql> SELECT * FROM INFORMATION_SCHEMA.ENGINES WHERE ENGINE='PERFORMANCE_SCHEMA'\G *************************** 1. row *************************** ENGINE: PERFORMANCE_SCHEMA SUPPORT: YES COMMENT: Performance Schema TRANSACTIONS: NO XA: NO SAVEPOINTS: NO mysql> SHOW ENGINES\G ... Engine: PERFORMANCE_SCHEMA Support: YES Comment: Performance Schema Transactions: NO XA: NO Savepoints: NO ...
Механизм хранения PERFORMANCE_SCHEMA
воздействует на таблицы в базе данных performance_schema
.
Вы можете сделать базу данных performance_schema
базой данных по
умолчанию так, чтобы ссылки на ее таблицы не были квалифицированы с
именем базы данных:
mysql> USE performance_schema;
Много примеров в этой главе принимают performance_schema
как базу данных по умолчанию.
Таблицы Performance Schema сохранены в базе данных
performance_schema
. Информация о структуре этой базы данных и ее
таблиц может быть получена как для любой другой базы данных, выбирая из
INFORMATION_SCHEMA
или при использовании
SHOW
. Например, используйте любой из
этих запросов, чтобы видеть, какие таблицы Performance Schema существуют:
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'performance_schema'; +------------------------------------------------+ | TABLE_NAME | +------------------------------------------------+ | accounts | | cond_instances | ... | events_stages_current | | events_stages_history | | events_stages_history_long | | events_stages_summary_by_account_by_event_name | | events_stages_summary_by_host_by_event_name | | events_stages_summary_by_thread_by_event_name | | events_stages_summary_by_user_by_event_name | | events_stages_summary_global_by_event_name | | events_statements_current | | events_statements_history | | events_statements_history_long | ... | file_instances | | file_summary_by_event_name | | file_summary_by_instance | | host_cache | | hosts | | memory_summary_by_account_by_event_name | | memory_summary_by_host_by_event_name | | memory_summary_by_thread_by_event_name | | memory_summary_by_user_by_event_name | | memory_summary_global_by_event_name | | metadata_locks | | mutex_instances | | objects_summary_global_by_type | | performance_timers | | replication_connection_configuration | | replication_connection_status | | replication_applier_configuration | | replication_applier_status | | replication_applier_status_by_coordinator | | replication_applier_status_by_worker | | rwlock_instances | | session_account_connect_attrs | | session_connect_attrs | | setup_actors | | setup_consumers | | setup_instruments | | setup_objects | | setup_timers | | socket_instances | | socket_summary_by_event_name | | socket_summary_by_instance | | table_handles | | table_io_waits_summary_by_index_usage | | table_io_waits_summary_by_table | | table_lock_waits_summary_by_table | | threads | | users | +------------------------------------------------+ mysql> SHOW TABLES FROM performance_schema; +------------------------------------------------------+ | Tables_in_performance_schema | +------------------------------------------------------+ | accounts | | cond_instances | | events_stages_current | | events_stages_history | | events_stages_history_long | ...
Число таблиц Performance Schema увеличится в течение долгого времени как выполнение дополнительных инструментов.
Название базы данных performance_schema
в нижнем регистре,
как и названия таблиц в ее пределах. Запросы должны определить
имена в нижнем регистре.
Чтобы видеть структуру отдельных таблиц, надо использовать
SHOW CREATE TABLE
:
mysql> SHOW CREATE TABLE setup_timers\G *************************** 1. row *************************** Table: setup_timers Create Table: CREATE TABLE `setup_timers` ( `NAME` varchar(64) NOT NULL, `TIMER_NAME` enum('CYCLE','NANOSECOND','MICROSECOND','MILLISECOND','TICK') NOT NULL) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8
Структура таблицы также доступна, выбирая из таких таблиц, как
INFORMATION_SCHEMA.COLUMNS
или при использовании запросов SHOW COLUMNS
.
Таблицы в performance_schema
могут быть сгруппированы
согласно типу информации в них: текущие события, истории событий и резюме,
экземпляры объектов и информацию конфигурации. Следующие примеры иллюстрируют
несколько вариантов использования для этих таблиц. Для получения дальнейшей
информации о таблицах в каждой группе см.
раздел 23.9.
Первоначально, не все инструменты и потребители включены, таким образом, performance schema не собирает все события. Чтобы включить всех их и включить синхронизацию событий, выполните два запроса (количество строк может отличаться в зависимости от версии MySQL):
mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'; Query OK, 560 rows affected (0.04 sec) mysql> UPDATE setup_consumers SET ENABLED = 'YES'; Query OK, 10 rows affected (0.00 sec)
Чтобы видеть, что сервер делает в настоящее время, исследуйте таблицу
events_waits_current
. Это содержит одну строку на поток, показывая новое следившее за
развитием событие каждого потока:
mysql> SELECT * FROM events_waits_current\G *************************** 1. row *************************** THREAD_ID: 0 EVENT_ID: 5523 EVENT_NAME: wait/synch/mutex/mysys/THR_LOCK::mutex SOURCE: thr_lock.c:525 TIMER_START: 201660494489586 TIMER_END: 201660494576112 TIMER_WAIT: 86526 SPINS: NULL OBJECT_SCHEMA: NULL OBJECT_NAME: NULL OBJECT_TYPE: NULL OBJECT_INSTANCE_BEGIN: 142270668 NESTING_EVENT_ID: NULL OPERATION: lock NUMBER_OF_BYTES: NULL FLAGS: 0 ...
Этот случай указывает, что поток 0 ждал 86526 пикосекунд, чтобы приобрести
блокировку на THR_LOCK::mutex
, mutex в подсистеме
mysys
. Первые несколько столбцов
предоставляют следующую информацию:
ID столбца указывают, какой поток прибывает и число событий.
EVENT_NAME
указывает на то, что было инструментовано и
SOURCE
указывает, какой исходный файл
содержит инструментованный код.TIMER_END
и TIMER_WAIT
NULL
.
Значения таймера приблизительны и выражены в пикосекундах. Для информации о
таймерах и времени событий см.
раздел 23.2.3.1.
Таблицы истории содержат тот же самый вид строк как таблица текущих
событий, но имеют больше строк и показывают то, что сервер делал. Таблицы
events_waits_history
и
events_waits_history_long
содержат самые свежие 10 событий на
поток и новые 10000 событий, соответственно. Например, чтобы увидеть
информацию для недавних событий, произведенных потоком 13, сделайте это:
mysql> SELECT EVENT_ID, EVENT_NAME, TIMER_WAIT FROM events_waits_history WHERE THREAD_ID = 13 ORDER BY EVENT_ID; +----------+-----------------------------------------+------------+ | EVENT_ID | EVENT_NAME | TIMER_WAIT | +----------+-----------------------------------------+------------+ | 86 | wait/synch/mutex/mysys/THR_LOCK::mutex | 686322 | | 87 | wait/synch/mutex/mysys/THR_LOCK_malloc | 320535 | | 88 | wait/synch/mutex/mysys/THR_LOCK_malloc | 339390 | | 89 | wait/synch/mutex/mysys/THR_LOCK_malloc | 377100 | | 90 | wait/synch/mutex/sql/LOCK_plugin | 614673 | | 91 | wait/synch/mutex/sql/LOCK_open | 659925 | | 92 | wait/synch/mutex/sql/THD::LOCK_thd_data | 494001 | | 93 | wait/synch/mutex/mysys/THR_LOCK_malloc | 222489 | | 94 | wait/synch/mutex/mysys/THR_LOCK_malloc | 214947 | | 95 | wait/synch/mutex/mysys/LOCK_alarm | 312993 | +----------+-----------------------------------------+------------+
Поскольку новые события добавлены к таблице истории, от более старых событий отказываются, если таблица полна.
Сводные таблицы предоставляют соединенную информацию для всех событий в
течение долгого времени. Таблицы в этой группе суммируют данные событий
по-разному. Чтобы видеть, какие инструменты были запущены большинство раз или
заняли больше времени, сортируют таблицу
events_waits_summary_global_by_event_name
по столбцу
COUNT_STAR
или SUM_TIMER_WAIT
, которые
соответствуют COUNT(*)
или SUM(TIMER_WAIT)
,
соответственно, вычисленным по всем событиям:
mysql> SELECT EVENT_NAME, COUNT_STAR FROM events_waits_summary_global_by_event_name ORDER BY COUNT_STAR DESC LIMIT 10; +---------------------------------------------------+------------+ | EVENT_NAME | COUNT_STAR | +---------------------------------------------------+------------+ | wait/synch/mutex/mysys/THR_LOCK_malloc | 6419 | | wait/io/file/sql/FRM | 452 | | wait/synch/mutex/sql/LOCK_plugin | 337 | | wait/synch/mutex/mysys/THR_LOCK_open | 187 | | wait/synch/mutex/mysys/LOCK_alarm | 147 | | wait/synch/mutex/sql/THD::LOCK_thd_data | 115 | | wait/io/file/myisam/kfile | 102 | | wait/synch/mutex/sql/LOCK_global_system_variables | 89 | | wait/synch/mutex/mysys/THR_LOCK::mutex | 89 | | wait/synch/mutex/sql/LOCK_open | 88 | +---------------------------------------------------+------------+ mysql> SELECT EVENT_NAME, SUM_TIMER_WAIT FROM events_waits_summary_global_by_event_name ORDER BY SUM_TIMER_WAIT DESC LIMIT 10; +----------------------------------------+----------------+ | EVENT_NAME | SUM_TIMER_WAIT | +----------------------------------------+----------------+ | wait/io/file/sql/MYSQL_LOG | 1599816582 | | wait/synch/mutex/mysys/THR_LOCK_malloc | 1530083250 | | wait/io/file/sql/binlog_index | 1385291934 | | wait/io/file/sql/FRM | 1292823243 | | wait/io/file/myisam/kfile | 411193611 | | wait/io/file/myisam/dfile | 322401645 | | wait/synch/mutex/mysys/LOCK_alarm | 145126935 | | wait/io/file/sql/casetest | 104324715 | | wait/synch/mutex/sql/LOCK_plugin | 86027823 | | wait/io/file/sql/pid | 72591750 | +----------------------------------------+----------------+
Эти результаты показывают, что THR_LOCK_malloc
востребована с точки зрения того, как часто используется и количества
времени, которое потоки ждут, пытаясь приобрести это.
THR_LOCK_malloc
mutex используется только в отладке.
Таблицы документируют, какие типы объектов инструментованы.
Инструментованный объект, когда используется сервером, производит случай. Эти
таблицы обеспечивают имена событий и примечания или информацию о статусе.
Например, таблица
file_instances
приводит случаи инструментов для операций
ввода/вывода файла и их связанных файлов:
mysql> SELECT * FROM file_instances\G *************************** 1. row *************************** FILE_NAME: /opt/mysql-log/60500/binlog.000007 EVENT_NAME: wait/io/file/sql/binlog OPEN_COUNT: 0 *************************** 2. row *************************** FILE_NAME: /opt/mysql/60500/data/mysql/tables_priv.MYI EVENT_NAME: wait/io/file/myisam/kfile OPEN_COUNT: 1 *************************** 3. row *************************** FILE_NAME: /opt/mysql/60500/data/mysql/columns_priv.MYI EVENT_NAME: wait/io/file/myisam/kfile OPEN_COUNT: 1 ...
Таблицы установки используются, чтобы сконфигурировать и вывести на экран
контролирующие характеристики. Например, чтобы видеть, какие таймеры
событий выбраны, запросите таблицы
setup_timers
:
mysql> SELECT * FROM setup_timers; +-------------+-------------+ | NAME | TIMER_NAME | +-------------+-------------+ | idle | MICROSECOND | | wait | CYCLE | | stage | NANOSECOND | | statement | NANOSECOND | | transaction | NANOSECOND | +-------------+-------------+
setup_instruments
перечисляет набор инструментов, для которых события могут быть
собраны и показывает, которые из них включены:
mysql> SELECT * FROM setup_instruments; +---------------------------------------------------+---------+-------+ | NAME | ENABLED | TIMED | +---------------------------------------------------+---------+-------+ ... | wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES | | wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES | | wait/synch/mutex/sql/LOCK_lock_db | YES | YES | | wait/synch/mutex/sql/LOCK_manager | YES | YES | ... | wait/synch/rwlock/sql/LOCK_grant | YES | YES | | wait/synch/rwlock/sql/LOGGER::LOCK_logger | YES | YES | | wait/synch/rwlock/sql/LOCK_sys_init_connect | YES | YES | | wait/synch/rwlock/sql/LOCK_sys_init_slave | YES | YES | ... | wait/io/file/sql/binlog | YES | YES | | wait/io/file/sql/binlog_index | YES | YES | | wait/io/file/sql/casetest | YES | YES | | wait/io/file/sql/dbopt | YES | YES | ...
Чтобы понять, как интерпретировать инструментальные имена см. раздел 23.4.
Чтобы управлять тем, собраны ли события для инструмента, устанавливайте
значение ENABLED
в YES
или NO
:
mysql> UPDATE setup_instruments SET ENABLED = 'NO' WHERE NAME = 'wait/synch/mutex/sql/LOCK_mysql_create_db';
Performance Schema использует собранные события, чтобы обновить таблицы в
performance_schema
, которые действуют как
потребители информации о событии. Таблица
setup_consumers
приводит доступных потребителей и которые включены:
mysql> SELECT * FROM setup_consumers; +----------------------------------+---------+ | NAME | ENABLED | +----------------------------------+---------+ | events_stages_current | NO | | events_stages_history | NO | | events_stages_history_long | NO | | events_statements_current | YES | | events_statements_history | YES | | events_statements_history_long | NO | | events_transactions_current | NO | | events_transactions_history | NO | | events_transactions_history_long | NO | | events_waits_current | NO | | events_waits_history | NO | | events_waits_history_long | NO | | global_instrumentation | YES | | thread_instrumentation | YES | | statements_digest | YES | +----------------------------------+---------+
Чтобы управлять тем, поддерживает ли Performance Schema как место
назначения для информации о событии, устанавливайте ENABLED
.
Для получения дополнительной информации о таблицах установки и как использовать их, чтобы управлять набором событий см. раздел 23.2.3.2.
Есть некоторые разные таблицы, которые не попадают ни в одну из
предыдущих групп. Например,
performance_timers
перечисляет доступные таймеры событий и их характеристики. Для
информации о таймерах см.
раздел 23.2.3.1.
Чтобы использовать MySQL Performance Schema, эти соображения конфигурации применяются:
Performance Schema должна быть сконфигурирована в ходе сборки MySQL Server, чтобы она была доступна. Performance Schema включена в двоичные дистрибутивы MySQL. Если Вы создаете пакет из исходных текстов, Вы должны гарантировать, что он сконфигурирован как описано в разделе 23.2.1 .
Если Вы создаете 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_
CMake в
разделе 2.8.4.XXX
Если Вы устанавливаете 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 доступна, а не то, что это включено. Чтобы включить, Вы
должны сделать так при запуске сервера, как описано в следующем разделе.
Предполагая, что Performance Schema доступна, она включена по умолчанию.
Чтобы включить или отключить это явно, запустите сервер с переменной
performance_schema
, установленной к соответствующему значению. Например, используйте
эти строки в Вашем файле my.cnf
:
[mysqld] performance_schema=ON
Если сервер неспособен выделить какой-либо внутренний буфер во время
инициализации Performance Schema, то Performance Schema отключается и
устанавливает
performance_schema
в OFF
, а
сервер работает без инструментовки.
Performance Schema также разрешает настроить инструмент и потребительскую конфигурацию при запуске сервера.
Чтобы управлять инструментом при запуске сервера, используйте опцию этой формы:
--performance-schema-instrument='instrument_name
=value
'
Здесь instrument_name
инструментальное имя, такое
как wait/synch/mutex/sql/LOCK_open
, а
value
одно из этих значений:
OFF
, FALSE
или
0
: Отключите инструмент.
ON
, TRUE
или 1
:
Включить и измерять время.COUNTED
: Включить и считать инструмент.Каждая опция
--performance-schema-instrument
может определить только одно
инструментальное имя, но много копий опции могут быть приведены, чтобы
сконфигурировать много инструментов. Кроме того, образцы разрешены в
инструментальных именах, чтобы сконфигурировать инструменты, которые
соответствуют образцу. Чтобы сконфигурировать все инструменты синхронизации
условия как включенные и считающиеся, используйте эту опцию:
--performance-schema-instrument='wait/synch/cond/%=COUNTED'
Чтобы отключить все инструменты, используйте эту опцию:
--performance-schema-instrument='%=OFF'
Исключение: инструменты memory/performance_schema/%
встроены и не могут быть отключены при запуске.
Более длинные инструментальные строки имен имеют приоритет над более коротким образцами имен, независимо от порядка. Для информации об определении образцов, чтобы выбрать инструменты, см. раздел 23.2.3.9.
Проигнорировано непризнанное инструментальное имя. Возможно, что плагин, установленный позже, может создать инструмент, в котором имя признано и сконфигурировано.
Чтобы управлять потребителем при запуске сервера, используйте опцию этой формы:
--performance-schema-consumer-consumer_name
=value
Здесь consumer_name
потребительское имя, такое как
events_waits_history
, а value
одно из этих значений:
OFF
, FALSE
или 0
:
Не собирать события для потребителя.
ON
, TRUE
или 1
:
Собирать события для потребителя.Например, чтобы включить потребителя events_waits_history
,
используйте эту опцию:
--performance-schema-consumer-events-waits-history=ON
Разрешенные потребительские имена могут быть найдены, исследуя таблицу
setup_consumers
.
Образцы не разрешены. Потребитель называется в таблице
setup_consumers
с применением подчеркивания, но для потребительского набора при запуске тире
и подчеркивания в пределах имени эквивалентны.
Performance Schema включает несколько системных переменных, которые предоставляют информацию о конфигурации:
mysql> SHOW VARIABLES LIKE 'perf%'; +--------------------------------------------------------+-------+ | Variable_name | Value | +--------------------------------------------------------+-------+ | performance_schema | ON | | performance_schema_accounts_size | 100 | | performance_schema_digests_size | 200 | | performance_schema_events_stages_history_long_size | 10000 | | performance_schema_events_stages_history_size | 10 | | performance_schema_events_statements_history_long_size | 10000 | | performance_schema_events_statements_history_size | 10 | | performance_schema_events_waits_history_long_size | 10000 | | performance_schema_events_waits_history_size | 10 | | performance_schema_hosts_size | 100 | | performance_schema_max_cond_classes | 80 | | performance_schema_max_cond_instances | 1000 | ...
Переменная
performance_schema
ON
или OFF
, чтобы
указать, включена ли Performance Schema. Другие переменные указывают на
табличные размеры (число строк) или значения распределения памяти.
С включенной Performance Schema число случаев Performance Schema затрагивает память сервера, возможно в большой степени. Performance Schema автомасштабирует много параметров, чтобы использовать память только как требуется, см. раздел 23.14.
Чтобы изменить значение системных переменных Performance Schema,
установите их при запуске сервера. Например, поместите следующие строки в
файл my.cnf
, чтобы изменить размеры таблиц истории для события:
[mysqld] performance_schema performance_schema_events_waits_history_size=20 performance_schema_events_waits_history_long_size=15000
Performance Schema автоматически измеряет значения нескольких из ее параметров при запуске сервера, если они не установлены явно. Например, это измеряет параметры, которые управляют размерами событий. Performance Schema выделяет память, масштабируя ее использование к фактической загрузке сервера вместо того, чтобы выделить всю память, которая требуется во время запуска сервера. Следовательно, много параметров калибровки не должны быть установлены вообще. Чтобы видеть, какие параметры автоизмерены или автомасштабируются, используйте mysqld --verbose --help и исследуйте описания опции.
Для каждого авторазмерного параметра, который не установлен при запуске сервера (или установле в -1) Performance Schema определяет, как установить значение, основанное на значении следующих системных значений, которые рассматривают как подсказки о том, как Вы сконфигурировали свой сервер MySQL:
max_connections open_files_limit table_definition_cache table_open_cache
Чтобы переопределить автокалибровку или автомасштабирование для данного параметра, установите это в значение не -1 при запуске. В этом случае Performance Schema назначает этому указанное значение.
Во временя выполнения SHOW
VARIABLES
выводит на экран фактические значения, к которым были
установлены автоизмеренные параметры. Автомасштабируемые параметры выводятся
на экран со значением -1.
Если Performance Schema отключена, ее авторазмерные и автомасштабируемые
параметры остаются установленными в -1 и
SHOW VARIABLES
покажет -1.
Таблицы установки 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
,
когда Вы запускаете сервер.
События собраны посредством инструментовки, добавленной к исходному коду сервера. Инструментальные события времени обеспечивают сведения о том, сколько времени события берут. Также возможно сконфигурировать инструменты, чтобы не собирать информацию синхронизации. Этот раздел обсуждает доступные таймеры, их характеристики, и как значения синхронизации представлены в событиях.
Две таблицы Performance Schema предоставляют информацию о таймере:
performance_timers
перечисляет доступные
таймеры и их характеристики.
setup_timers
указывает, какие таймеры используются для каких инструментов.Каждая строка таймера в
setup_timers
должна обратиться к одному из таймеров, перечисленных
в performance_timers
.
Таймеры изменяются по точности и издержкам. Чтобы видеть, какие таймеры
доступны и их характеристики, проверьте таблицу
performance_timers
:
mysql> SELECT * FROM performance_timers; +-------------+-----------------+------------------+----------------+ | TIMER_NAME | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD | +-------------+-----------------+------------------+----------------+ | CYCLE | 2389029850 | 1 | 72 | | NANOSECOND | 1000000000 | 1 | 112 | | MICROSECOND | 1000000 | 1 | 136 | | MILLISECOND | 1036 | 1 | 168 | | TICK | 105 | 1 | 2416 | +-------------+-----------------+------------------+----------------+
У столбцов есть эти значения:
TIMER_NAME
показывает названия доступных таймеров.
CYCLE
обращается к таймеру, который основан на счетчике цикла
центрального процессора. Вы можете использовать таймеры в
setup_timers
,
которые не имеют NULL
в других столбцах. Если значения,
связанные с данным именем таймера, NULL
, этот таймер не
поддержан на Вашей платформе.
TIMER_FREQUENCY
указывает на число модулей таймера в
секунду. Для счетчика циклов частота вообще связана со скоростью центрального
процессора. Показанное значение было получено на системе 2.4GHz.
Другие таймеры основаны на фиксированных долях секунд. Для TICK
частота может изменяться платформой (например, некоторые используют 100
tick/секунду, другие 1000 tick/секунду).TIMER_RESOLUTION
указывает на число модулей таймера,
которыми таймер оценивает увеличение за один раз. Если у таймера есть
разрешение 10, его значение увеличивается на 10 каждый раз.TIMER_OVERHEAD
минимальное число циклов, чтобы получить одну
синхронизацию с данным таймером. Издержки на событие являются удвоенным
значением, выведенным на экран, потому что таймер вызван в начале и в конце.
Чтобы видеть, который таймеры работают или изменить таймеры, получите
доступ к таблице setup_timers
:
mysql> SELECT * FROM setup_timers; +-------------+-------------+ | NAME | TIMER_NAME | +-------------+-------------+ | idle | MICROSECOND | | wait | CYCLE | | stage | NANOSECOND | | statement | NANOSECOND | | transaction | NANOSECOND | +-------------+-------------+ mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND' WHERE NAME = 'idle'; mysql> SELECT * FROM setup_timers; +-------------+-------------+ | NAME | TIMER_NAME | +-------------+-------------+ | idle | MICROSECOND | | wait | CYCLE | | stage | NANOSECOND | | statement | NANOSECOND | | transaction | NANOSECOND | +-------------+-------------+
По умолчанию Performance Schema использует лучший таймер, доступный для каждого инструментального типа, но Вы можете выбрать другой.
Для событий ожидания самый важный критерий это уменьшение издержек, таким
образом использование таймера CYCLE
является лучшим.
Время, которое запрос (или этап) занимает, чтобы выполниться,
находится в общих порядках величины, больше чем время, которое требуется,
чтобы выполнить только ожидание. Для запросов времени самым важным критерием
должна быть точная мера, которая не затронута изменениями в частоте
процессора, таким образом использование таймера, который не основан на
циклах, является лучшим. Таймер по умолчанию для запросов
NANOSECOND
. Дополнительные издержки
по сравнению с таймером CYCLE
не являются существенными, потому
что являются порядком величин меньше по сравнению со временем центрального
процессора, используемым, чтобы выполнить запрос непосредственно.
Использование таймера CYCLE
не обладает никаким преимуществом
здесь, только недостатками.
Точность, предлагаемая счетчиком цикла, зависит от скорости процессора.
Если процессор достигает 1 ГГц (один миллиард циклов/секунду) или выше,
счетчик цикла поставляет точность наносекунды. Использование счетчика цикла
намного более дешево, чем получение фактического времени суток. Например,
стандартная функция gettimeofday()
может взять сотни циклов,
что является недопустимыми издержками для того, что может произойти тысячи
или миллионы раз в секунду.
У счетчиков цикла также есть недостатки:
Конечные пользователи ожидают видеть синхронизации в модулях стенных часов такие, как доли секунды. Преобразование из циклов в доли секунд может быть дорогим. Поэтому преобразование быстрая и довольно грубая работа умножения.
RDTSC
(ассемблер, а не инструкция C) и для операционной
системы теоретически возможно препятствовать тому, чтобы программы
пользовательского режима использовали это.MySQL работает со счетчиками цикла на x386 (Windows, OS X, Linux, Solaris и другие разновидности Unix), PowerPC и IA-64.
У строк в таблицах Performance Schema, которые хранят текущие и
исторические события, есть три столбца, чтобы представить информацию о
синхронизации: TIMER_START
и TIMER_END
указывают,
когда случай запустился и закончился, а TIMER_WAIT
указывает на продолжительность события.
Таблица
setup_instruments
имеет столбец ENABLED
, чтобы
указать на инструменты, для которых можно собрать события. У таблицы также
есть столбец TIMED
, чтобы указать, какие инструменты рассчитаны.
Если инструмент не включен, он не производит событий. Если включенный
инструмент не рассчитан, события, произведенные инструментом, имеют
NULL
для значений таймера TIMER_START
,
TIMER_END
и TIMER_WAIT
. Это в свою очередь
заставляет проигнорировать те значения, вычисляя сумму, минимум, максимум и
средние временные оценки в сводных таблицах.
Внутренне, времена в пределах событий сохранены в модулях, данных таймером в действительности, когда синхронизация событий начинается. Для отображения, когда события получены от таблиц Performance Schema времена показываются в пикосекундах и нормализуются к стандартному модулю, независимо от которого выбран таймер.
Модификации таблицы
setup_timers
применяются немедленно. События, уже происходящие, могут использовать
оригинальный таймер в течение времени начала и новый таймер в течение времени
окончания. Чтобы избежать непредсказуемых результатов после того, как Вы
производите изменения таймера, надо использовать
TRUNCATE TABLE
, чтобы
сбрасывать статистику Performance Schema.
Базовая линия таймера (нулевое время) происходит при
инициализации Performance Schema во время запуска сервера. Значения
TIMER_START
и TIMER_END
в событиях представляют пикосекунды, начиная с базовой линии. Значения
TIMER_WAIT
указывают продолжительности в пикосекундах.
Значения пикосекунды в событиях приблизительны. Их точность подвергается
обычным формам ошибки, связанной с преобразованием от одного модуля до
другого. Если таймер CYCLE
используется, и уровень процессора
изменяется, мог бы быть дрейф. По этим причинам неразумно смотреть на
значение TIMER_START
как на точную меру времени, начиная с
запуска сервера. С другой стороны, разумно использовать
TIMER_START
или TIMER_WAIT
в ORDER BY
,
чтобы упорядочить события по времени запуска или продолжительности.
У выбора пикосекунд в событиях, а не таких значений, как микросекунды
есть исполнительное основание. Одна цель выполнения состояла в том, чтобы
показать результаты в однородной единице измерения времени, независимо от
таймера. В идеальном мире эта единица измерения времени была бы похожа на
модуль стенных часов и была бы разумно точна, другими словами, микросекунды.
Но преобразовать циклы или наносекунды к микросекундам, было бы необходимо
выполнить деление для каждой инструментовки. Деление дорого на многих
платформах. Умножение не дорого, так что оно и используется.
Поэтому, единица измерения времени целое число, полученное из максимально
возможного TIMER_FREQUENCY
, используя множитель, достаточно
большой, чтобы гарантировать, что нет никакой крупной потери точности.
Результат состоит в том, что единица измерения времени пикосекунда
. Эта точность является поддельной, но решение минимизирует издержки.
В то время как ожидание, этап, запрос или операционный случай выполняются, соответствующие таблицы текущих событий выводят на экран информацию о синхронизации текущих событий:
events_waits_current events_stages_current events_statements_current events_transactions_current
Чтобы позволить определить, сколько времени завершенный случай работал, столбцы таймера установлены следующим образом:
TIMER_START
заполнен.
TIMER_END
заполнен текущим значением таймера.TIMER_WAIT
заполнен временем, прошедшим до сих пор
(TIMER_END
-TIMER_START
).События, которые еще не завершились, имеют значение
END_EVENT_ID
NULL
.
Чтобы оценить прошедшее время для случая, используйте столбец
TIMER_WAIT
. Поэтому, чтобы идентифицировать события, которые еще
не завершились и заняли больше времени, чем N
пикосекунд к настоящему времени, приложения могут использовать
это выражение в запросах:
WHERE END_EVENT_ID IS NULL AND TIMER_WAIT > N
Идентификация событий как только описано предполагает, что соответствующие
инструменты имеют ENABLED
и TIMED
установленные в
YES
, а соответствующие потребители включены.
События обработаны способом производителя/потребителя:
Инструментованный код производит события, которые будут собраны.
Таблица setup_instruments
приводит инструменты, для которых могут быть собраны события,
включены ли они и (для включенных инструментов), собирать
ли информацию синхронизации:
mysql> SELECT * FROM setup_instruments; +---------------------------------------------------+---------+-------+ | NAME | ENABLED | TIMED | +---------------------------------------------------+---------+-------+ ... | wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES | | wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES | | wait/synch/mutex/sql/LOCK_lock_db | YES | YES | | wait/synch/mutex/sql/LOCK_manager | YES | YES | ...
Таблица
setup_instruments
обеспечивает наиболее каноническую форму
управления производством событий. Чтобы далее усовершенствовать производство
событий, основанное на типе объекта или проверяемого потока, другие таблицы
могут использоваться как описано в
разделе 23.2.3.3.
setup_consumers
приводит типы потребителей, в которые можно
послать информацию о событии и включены ли они:
mysql> SELECT * FROM setup_consumers; +----------------------------------+---------+ | NAME | ENABLED | +----------------------------------+---------+ | events_stages_current | NO | | events_stages_history | NO | | events_stages_history_long | NO | | events_statements_current | YES | | events_statements_history | YES | | events_statements_history_long | NO | | events_transactions_current | NO | | events_transactions_history | NO | | events_transactions_history_long | NO | | events_waits_current | NO | | events_waits_history | NO | | events_waits_history_long | NO | | global_instrumentation | YES | | thread_instrumentation | YES | | statements_digest | YES | +----------------------------------+---------+
Фильтрация может быть сделана на различных этапах исполнительного контроля:
Предварительная фильтрация. Это сделано, изменяя конфигурацию Performance Schema так, чтобы только определенные типы событий были собраны от производителей, и собранные события обновляют только определенных потребителей. Чтобы сделать это, включите или отключите инструменты или потребителей. Предварительная фильтрация сделана Performance Schema и имеет глобальный эффект, который относится ко всем пользователям.
Причины использовать предварительную фильтрацию:
Уменьшить издержки. Издержки Performance Schema должны быть минимальны даже со всеми включенными инструментами, но возможно Вы хотите уменьшить их далее. Или Вы не заботитесь о событиях синхронизации и хотите отключить код синхронизации, чтобы устранить издержки синхронизации.
Постфильтрация. Это вовлекает
использование WHERE
в запросах, которые выбирают информацию из
таблиц Performance Schema, чтобы определить, какое из доступных событий Вы
хотите видеть. Постфильтрация выполнена в расчёте на пользователя, потому что
отдельные пользователи выбирают, какие из доступных
событий представляют интерес.
Причины использовать постфильтрацию:
Избежать принятия решений для отдельных пользователей о том, информация о каких событиях представляет интерес.
Следующие разделы обеспечивают больше деталей о предварительной фильтрации и обеспечивают направления для того, чтобы назвать инструменты или потребителей в фильтрации операций. Для информации о написании запросов, чтобы получить информацию (постфильтрация) см. раздел 23.3.
Предварительная фильтрация сделана Performance Schema и имеет глобальный эффект, который относится ко всем пользователям. Предварительная фильтрация может быть применена к производителю или к потребителю обработки событий:
Чтобы сконфигурировать предварительную фильтрацию на этапе производителя, несколько таблиц могут использоваться:
setup_instruments
указывает, какие инструменты доступны.
Инструмент, отключенный в этой таблице, не производит событий независимо от
содержания других связанных с производством таблиц. Инструменту, включенному
в этой таблице, разрешают произвести события, согласно
содержанию других таблиц.
setup_objects
контролирует особые таблицы Performance Schema и хранит объекты программы.
threads
указывает, включен ли контроль для каждого потока сервера.setup_actors
определяет начальное контрольное состояние
для новых потоков переднего плана.Чтобы сконфигурировать предварительную фильтрацию на потребительском
этапе, измените таблицу
setup_consumers
. Это определяет места назначения, в которые
посылают события. Если данный случай не пошлют ни к какому месту назначения
(то есть, он не будет потребляться), Performance Schema не производит его.
Модификации любой из этих таблиц действуют немедленно, за исключением
того, что модификации
setup_actors
влияют только на потоки переднего плана, созданные
после модификации, а не на существующие потоки.
Когда Вы изменяете контролирующую конфигурацию, Performance Schema
не сбрасывает таблицы истории. События, уже собранные, остаются в текущих
событиях и таблицах истории пока не перемещены более новыми событиями. Если
Вы отключаете инструменты, Вы, возможно, должны были бы ждать некоторое время
прежде, чем события для них перемещены более новыми мероприятиями.
Альтернативно, можно использовать
TRUNCATE TABLE
, чтобы
освободить таблицы истории.
После произведения изменений инструментовки Вы могли бы хотеть усечь
сводные таблицы. Вообще, эффект состоит в том, чтобы сбросить сводные столбцы
к 0 или NULL
, а не удалить строки. Это могло бы быть полезно,
например, после того, как Вы произвели изменение конфигурации во время
выполнения. Исключения к этому поведению усечения отмечены в отдельных
разделах сводной таблицы.
Следующие разделы описывают, как использовать определенные таблицы, чтобы управлять предварительной фильтрацией Performance Schema.
Таблица
setup_instruments
приводит доступные инструменты:
mysql> SELECT * FROM setup_instruments; +---------------------------------------------------+---------+-------+ | NAME | ENABLED | TIMED | +---------------------------------------------------+---------+-------+ ... | wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES | | wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES | | wait/synch/mutex/sql/LOCK_lock_db | YES | YES | | wait/synch/mutex/sql/LOCK_manager | YES | YES | ... | wait/synch/rwlock/sql/LOCK_grant | YES | YES | | wait/synch/rwlock/sql/LOGGER::LOCK_logger | YES | YES | | wait/synch/rwlock/sql/LOCK_sys_init_connect | YES | YES | | wait/synch/rwlock/sql/LOCK_sys_init_slave | YES | YES | ... | wait/io/file/sql/binlog | YES | YES | | wait/io/file/sql/binlog_index | YES | YES | | wait/io/file/sql/casetest | YES | YES | | wait/io/file/sql/dbopt | YES | YES | ...
Чтобы управлять, включен ли инструмент, устанавливайте столбец
ENABLED
в YES
или NO
.
Чтобы сконфигурировать, собирать ли информацию синхронизации для включенного
инструмента, установите TIMED
в YES
или
NO
. Установка TIMED
затрагивает табличное
содержание Performance Schema как описано в
разделе 23.2.3.1.
Модификации большинства строк
setup_instruments
действуют немедленно. Для некоторых инструментов модификации эффективны
только при запуске сервера, изменение их во время выполнения не имеет
никакого эффекта. Это затрагивает прежде всего mutexes, условия и rwlocks в
сервере, хотя могут быть другие инструменты, для которых это истина.
Таблица
setup_instruments
обеспечивает наиболее каноническую форму
управления производством событий. Чтобы далее усовершенствовать производство
событий, основанное на типе объекта или проверяемого потока, другие таблицы
могут использоваться как описано в
разделе 23.2.3.3.
Следующие примеры демонстрируют возможные операции на
setup_instruments
. Эти изменения, как другие операции перед фильтрацией, затрагивают всех
пользователей. Некоторые из этих запросов используют оператор
LIKE
и инструмент
соответствия образца. Для дополнительной информации об определении образцов,
чтобы выбрать инструменты см.
раздел 23.2.3.9.
Отключите все инструменты:
mysql> UPDATE setup_instruments SET ENABLED = 'NO';
Теперь никакие события не будут собраны.
mysql> UPDATE setup_instruments SET ENABLED = 'NO' WHERE NAME LIKE 'wait/io/file/%';
mysql> UPDATE setup_instruments SET ENABLED = IF(NAME LIKE 'wait/io/file/%', 'NO', 'YES');
mysys
:
mysql> UPDATE setup_instruments SET ENABLED = CASE WHEN NAME LIKE '%/mysys/%' THEN 'YES' ELSE 'NO' END;
mysql> UPDATE setup_instruments SET ENABLED = 'NO' WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';
mysql> UPDATE setup_instruments SET ENABLED = IF(ENABLED = 'YES','NO','YES') WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';
mysql> UPDATE setup_instruments SET TIMED = 'NO';
Таблица setup_objects
управляет, контролирует ли Performance Schema
особую таблицу и хранение объектов программы. Начальное содержимое
setup_objects
похоже на это:
mysql> SELECT * FROM setup_objects; +-------------+--------------------+-------------+---------+-------+ | OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED | +-------------+--------------------+-------------+---------+-------+ | EVENT | mysql | % | NO | NO | | EVENT | performance_schema | % | NO | NO | | EVENT | information_schema | % | NO | NO | | EVENT | % | % | YES | YES | | FUNCTION | mysql | % | NO | NO | | FUNCTION | performance_schema | % | NO | NO | | FUNCTION | information_schema | % | NO | NO | | FUNCTION | % | % | YES | YES | | PROCEDURE | mysql | % | NO | NO | | PROCEDURE | performance_schema | % | NO | NO | | PROCEDURE | information_schema | % | NO | NO | | PROCEDURE | % | % | YES | YES | | TABLE | mysql | % | NO | NO | | TABLE | performance_schema | % | NO | NO | | TABLE | information_schema | % | NO | NO | | TABLE | % | % | YES | YES | | TRIGGER | mysql | % | NO | NO | | TRIGGER | performance_schema | % | NO | NO | | TRIGGER | information_schema | % | NO | NO | | TRIGGER | % | % | YES | YES | +-------------+--------------------+-------------+---------+-------+
Модификации setup_objects
вступают в силу немедленно.
Столбец OBJECT_TYPE
указывает на тип объекта, к которому
применяется строка. TABLE
фильтрует табличные события
ввода/вывода (инструмент wait/io/table/sql/handler
) и
события блокировки (инструментwait/lock/table/sql/handler
).
Столбцы OBJECT_SCHEMA
и OBJECT_NAME
должны содержать буквальную схему или название объекта или '%'
,
чтобы соответствовать любому имени.
Столбец ENABLED
указывает, проверены ли соответствующие
объекты, а TIMED
указывает, собирать ли информацию
синхронизации. Установка TIMED
затрагивает табличное содержание
Performance Schema как описано в
разделе 23.2.3.1.
Эффект конфигурации объекта по умолчанию состоит в том, чтобы
инструментовать все объекты кроме тех, которые в базах данных
mysql
, INFORMATION_SCHEMA
и
performance_schema
. Таблицы в INFORMATION_SCHEMA
не инструментованы независимо от содержания
setup_objects
:
строка для information_schema.%
просто делает это значение по умолчанию явным.
Когда Performance Schema проверяет на соответствие в
setup_objects
,
это пытается найти более определенные соответствия сначала. Для строк,
которые соответствуют данному OBJECT_TYPE
, Performance Schema
проверяет строки в этом порядке:
Строки с OBJECT_SCHEMA='
и literal
'
OBJECT_NAME='
.literal
'
OBJECT_SCHEMA='literal
'
и OBJECT_NAME='%'
.OBJECT_SCHEMA='%'
и OBJECT_NAME='%'
.
Например, с таблицей db1.t1
Performance Schema смотрит
строки для TABLE
для 'db1'
и 't1'
,
потом для 'db1'
и '%'
, а уже потом для
'%'
и '%'
. Порядок, в котором соответствие
происходит такой, потому что различное соответствующие строки
setup_objects
могут иметь отличающиеся значения ENABLED
и TIMED
.
Для связанных с таблицей событий Performance Schema комбинирует содержание
setup_objects
с
setup_instruments
, чтобы определить, включить ли инструменты и включены ли
по времени инструменты:
Для таблиц, которые соответствуют строке в
setup_objects
,
табличные инструменты производят события только, если ENABLED
YES
в
setup_instruments
и
setup_objects
.
TIMED
в этих двух таблицах объединены так, чтобы
информация синхронизации была собрана только, когда
оба значения YES
.Для хранимых объектов программы Performance Schema берет столбцы
ENABLED
и TIMED
непосредственно из строки
setup_objects
.
Нет никакого объединения значений с
setup_instruments
.
Предположите, что
setup_objects
содержит следующие строки TABLE
,
которые относятся к db1
, db2
и db3
:
+-------------+---------------+-------------+---------+-------+ | OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED | +-------------+---------------+-------------+---------+-------+ | TABLE | db1 | t1 | YES | YES | | TABLE | db1 | t2 | NO | NO | | TABLE | db2 | % | YES | YES | | TABLE | db3 | % | NO | NO | | TABLE | % | % | YES | YES | +-------------+---------------+-------------+---------+-------+
Если связанный с объектом инструмент в
setup_instruments
имеет ENABLED
NO
, события для объекта не
отслеживаются. Если ENABLED
YES
,
контроль событий происходит согласно значению ENABLED
в соответствующей строке
setup_objects
:
События db1.t1
отслеживаются.
db1.t2
не отслеживаются.db2.t3
отслеживаются.db3.t4
не отслеживаются.db4.t5
отслеживаются.Подобная логика просит объединения столбцов TIMED
из
setup_instruments
и setup_objects
, чтобы определить, собирать ли информацию синхронизации событий.
Если у постоянной и временной таблиц есть то же самое имя, соответствующее
строке setup_objects
происходит тот же самый путь к обоим. Невозможно позволить
контролировать для одной таблицы, но не для другой.
Однако, каждая таблица инструментована отдельно.
Таблица threads
содержит строку для каждого потока сервера. Каждая строка содержит информацию
о потоке и указывает, включен ли контроль для этого. Для Performance Schema,
чтобы контролировать поток, эти вещи должны быть истиной:
Потребитель thread_instrumentation
в
setup_consumers
должен быть YES
.
threads.INSTRUMENTED
должен быть YES
.
setup_instruments
.Таблица threads
также показывает для каждого потока сервера, выполнить ли журналирование
исторического события. Это включает ожидание, подготовку, запрос и
операционное журналирование событий для этих таблиц:
events_waits_history events_waits_history_long events_stages_history events_stages_history_long events_statements_history events_statements_history_long events_transactions_history events_transactions_history_long
Для журналирования исторического события эти вещи должны быть истиной:
Соответствующие связанные с историей потребители в
setup_consumers
должны быть включены. Например, случай ожидания, протоколируемый в
events_waits_history
и
events_waits_history_long
требует соответствующих потребителей
events_waits_history
и events_waits_history_long
со статусом YES
.
threads.HISTORY
должен быть YES
.setup_instruments
.Для потоков переднего плана (следующих из соединений клиента), начальные
значения столбцов INSTRUMENTED
и HISTORY
в строках
таблицы threads
определены тем, соответствует ли учетная запись пользователя, связанная с
потоком, какой-либо строке в
setup_actors
. Значения прибывают из столбцов ENABLED
и HISTORY
соответствующих строк
setup_actors
.
Для фоновых потоков нет никакого связанного пользователя.
INSTRUMENTED
и HISTORY
YES
по умолчанию и setup_actors
не проверяется.
Стартовое содержание
setup_actors
похоже на это:
mysql> SELECT * FROM setup_actors; +------+------+------+---------+---------+ | HOST | USER | ROLE | ENABLED | HISTORY | +------+------+------+---------+---------+ | % | % | % | YES | YES | +------+------+------+---------+---------+
Столбцы HOST
и USER
должны содержать буквальный узел или имя пользователя, или
'%'
, чтобы соответствовать любому имени.
Столбцы ENABLED
и HISTORY
указывают, включить ли инструментовку и журналирование исторического события
для соответствующих потоков, согласно другим условиям, описанным ранее.
Когда Performance Schema проверяет на соответствие
каждый новый поток переднего плана в setup_actors
,
это пытается найти более определенные соответствия сначала, используя
столбцы USER
и HOST
(ROLE
не использован):
Строки с USER='
и
literal
'HOST='
.literal
'
USER='literal
'
и HOST='%'
.USER='%'
и
HOST='literal
'
.USER='%'
и HOST='%'
.Порядок, в котором соответствие происходит таков,
потому что различные соответствующие строки
setup_actors
могут иметь отличающиеся USER
и HOST
.
Это позволяет инструментовать и журналировать события, которые будут
применены выборочно на основе узла, пользователя или учетной записи
(комбинация пользователя и узла), исходя из значения столбцов:
ENABLED
и HISTORY
:
Когда лучшее соответствие строка с
ENABLED=YES
, значение INSTRUMENTED
для потока становится YES
. Когда лучшее соответствие строка с
HISTORY=YES
, HISTORY
для
потока становится YES
.
ENABLED=NO
, INSTRUMENTED
для потока становится
NO
. Когда лучшее соответствие строка с HISTORY=NO
,
HISTORY
для потока становится NO
.INSTRUMENTED
и
HISTORY
для потока становятся NO
.Столбцы ENABLED
и HISTORY
в строках
setup_actors
могут быть установлены в YES
или NO
независимо друг от друга. Это означает, что Вы можете включить инструментовку
отдельно от того, собираете ли Вы исторические события.
По умолчанию контроль и набор исторического события включен для всех
новых потоков переднего плана потому, что
setup_actors
первоначально содержит строку с '%'
для
HOST
и USER
. Чтобы выполнить более ограниченное
соответствие, например, позволить контролировать только для некоторых потоков
переднего плана, Вы должны изменить эту строку, потому что это соответствует
любому соединению, и добавить строки для более определенной комбинации
HOST
/USER
.
Предположите, что Вы изменяете
setup_actors
следующим образом:
UPDATE setup_actors SET ENABLED = 'NO', HISTORY = 'NO' WHERE HOST = '%' AND USER = '%'; INSERT INTO setup_actors (HOST,USER,ROLE,ENABLED,HISTORY) VALUES('localhost','joe','%','YES','YES'); INSERT INTO setup_actors (HOST,USER,ROLE,ENABLED,HISTORY) VALUES('hosta.example.com','joe','%','YES','NO'); INSERT INTO setup_actors (HOST,USER,ROLE,ENABLED,HISTORY) VALUES('%','sam','%','NO','YES');
UPDATE
изменяет соответствие по
умолчанию, чтобы отключить набор исторического события и инструментовку.
INSERT
добавляют строки для более определенных соответствий.
Теперь Performance Schema определяет, как установить значения
INSTRUMENTED
и HISTORY
для потока нового соединения следующим образом:
Если joe
соединяется с локального хоста, соединение
соответствует первой вставленной строке. INSTRUMENTED
и
HISTORY
для потока становятся YES
.
joe
соединяется с
hosta.example.com
, соединение соответствует второй
вставленной строке. INSTRUMENTED
для потока становится
YES
, а HISTORY
NO
.joe
соединяется с любого другого узла, это не идет ни в
какое сравнение. INSTRUMENTED
и HISTORY
для потока становятся NO
.sam
соединяется с любого узла, соединение
соответствует третей вставленной строке. INSTRUMENTED
для потока
становится NO
, а HISTORY
YES
.HOST
и USER
соответствуют
'%'
. Эта строка теперь имеет ENABLED
и
HISTORY
NO
, так что INSTRUMENTED
и
HISTORY
для потока становятся NO
.Модификации setup_actors
влияют только на потоки переднего плана, созданные после
модификации, а не на существующие потоки. Чтобы затронуть существующие
потоки, измените INSTRUMENTED
и HISTORY
строках
таблицы threads
.
setup_consumers
приводит доступные потребительские типы и то, которые включены:
mysql> SELECT * FROM setup_consumers; +----------------------------------+---------+ | NAME | ENABLED | +----------------------------------+---------+ | events_stages_current | NO | | events_stages_history | NO | | events_stages_history_long | NO | | events_statements_current | YES | | events_statements_history | YES | | events_statements_history_long | NO | | events_transactions_current | NO | | events_transactions_history | NO | | events_transactions_history_long | NO | | events_waits_current | NO | | events_waits_history | NO | | events_waits_history_long | NO | | global_instrumentation | YES | | thread_instrumentation | YES | | statements_digest | YES | +----------------------------------+---------+
Измените setup_consumers
, чтобы затронуть предварительную фильтрацию в потребителе
и определить места назначения, в которые посылают события. Чтобы включить или
отключить потребителя, установите ENABLED
в
YES
или NO
.
Модификации
setup_consumers
срабатывают немедленно.
Если Вы отключаете потребителя, сервер не тратит времени на поддержание места назначения для этого потребителя. Например, если Вы не заботитесь об информации об историческом событии, отключите потребителей истории:
mysql> UPDATE setup_consumers SET ENABLED = 'NO' WHERE NAME LIKE '%history%';
Потребительские настройки в
setup_consumers
имеют иерархию.
Следующие принципы применяются:
Места назначения, связанные с потребителем, не получают событий, если Performance Schema не проверяет потребителя.
Следующие списки описывают доступные потребительские значения. Для обсуждения нескольких потребительских конфигураций и их эффекта на инструментовку см. раздел 23.2.3.8.
Глобальные и потребители потока
global_instrumentation
потребитель высшего уровня.
Если global_instrumentation
NO
,
это отключает глобальную инструментовку. Все другие настройки более низкого
уровня и не проверены, не имеет значения, во что они установлены. Нет
глобальной или поточной информацим о потоке, и никакие одиночные события
не собраны в таблицах истории событий или текущих событиях. Если
global_instrumentation
YES
, Performance Schema
поддерживает информацию для глобальных состояний, а также проверяет
потребителей thread_instrumentation
.
thread_instrumentation
проверен только, если
global_instrumentation
YES
. Иначе, если
thread_instrumentation
NO
,
это отключает определенную для потока инструментовку, и все настройки низшего
уровня проигнорированы. Никакая информация не поддержана для потока, и
никакие одиночные события не собраны в таблицах истории событий или текущих
событиях. Если thread_instrumentation
YES
,
Performance Schema поддерживает определенную для потока информацию, а также
проверяет events_xxx
_current
.
Потребители событий ожидания
Эти потребители требуют установки обоих
global_instrumentation
и thread_instrumentation
в
YES
или они не проверены. Если проверены, они
действуют следующим образом:
events_waits_current
, если NO
,
отключает сбор индивидуальных событий ожидания в таблице
events_waits_current
. Если YES
, это включает сбор событий и
Performance Schema проверяет events_waits_history
и
events_waits_history_long
.
events_waits_history
не проверен, если
event_waits_current
NO
. Иначе
events_waits_history
NO
или YES
отключает или включает сбор событий в таблице
events_waits_history
.events_waits_history_long
не проверен, если
event_waits_current
NO
. Иначе
events_waits_history_long
NO
или YES
отключает или включает сбор событий в таблице
events_waits_history_long
.Потребители событий этапа
Эти потребители требуют global_instrumentation
и
thread_instrumentation
в YES
или они не проверены. Если проверены, действуют следующим образом:
events_stages_current
, если NO
,
отключает сбор отдельных событий этапа в таблице
events_stages_current
. Если YES
, это включает сбор этапов событий, и
Performance Schema проверяет events_stages_history
и
events_stages_history_long
.
events_stages_history
не проверен, если
event_stages_current
NO
. Иначе
events_stages_history
NO
или YES
отключает или включает сбор событий этапа в
events_stages_history
.events_stages_history_long
не проверен, если
event_stages_current
NO
. Иначе
events_stages_history_long
NO
или YES
отключает или включает сбор событий этапа в
events_stages_history_long
.Потребители событий запроса
Эти потребители требуют global_instrumentation
и
thread_instrumentation
в YES
или они не проверены. Если проверены, действуют следующим образом:
events_statements_current
, если NO
,
отключает сбор отдельных событий запроса в таблице
events_statements_current
. Если YES
,
это включает сбор запросов событий, и Performance Schema проверяет
events_statements_history
и
events_statements_history_long
.
events_statements_history
не проверен, если
events_statements_current
NO
. Иначе
events_statements_history
NO
или YES
отключает или включает сбор событий запроса в таблице
events_statements_history
.events_statements_history_long
не проверен, если
events_statements_current
NO
. Иначе
events_statements_history_long
NO
или
YES
отключает или включает сбор событий запроса в таблице
events_statements_history_long
.Операционные потребители событий
Эти потребители требуют global_instrumentation
и
thread_instrumentation
YES
или они не проверены. Если проверены, они действуют следующим образом:
events_transactions_current
, если
NO
, отключает сбор отдельных операционных событий в таблице
events_transactions_current
. Если YES
,
это включает сбор операционных событий, и Performance Schema проверяет
events_transactions_history
и
events_transactions_history_long
.
events_transactions_history
не проверен, если
events_transactions_current
NO
. Иначе
events_transactions_history
NO
или YES
отключает или включает сбор операционных событий в таблице
events_transactions_history
.events_transactions_history_long
не проверен, если
events_transactions_current
NO
. Иначе
events_transactions_history_long
NO
или YES
отключает или включает сбор операционных событий в таблице
events_transactions_history_long
.Потребитель обзора запросов
Этот потребитель требует global_instrumentation
YES
или это не проверено. Нет никакой зависимости от
потребителей событий запросов, таким образом, Вы можете получить статистику
обзоров, не имея необходимости собирать статистические данные в
events_statements_current
, что выгодно с точки зрения издержек.
Наоборот, Вы можете вложить детализированные запросы
events_statements_current
без обзоров (столбцы DIGEST
и DIGEST_TEXT
должны быть NULL
).
Потребительские настройки в таблице
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
_currentevents_waits_current
включен,
events_waits_history
и
events_waits_history_long
проверены.
Каждое из следующих описаний конфигурации указывает, какие элементы установки проверки Performance Schema выводят таблицы, которые она поддерживает (то есть, для которых таблиц она собирает информацию).
Состояние конфигурации сервера:
mysql> SELECT * FROM setup_consumers; +---------------------------+---------+ | NAME | ENABLED | +---------------------------+---------+ | global_instrumentation | NO | ... +---------------------------+---------+
В этой конфигурации ничто не инструментовано.
Элементы установки проверяют:
Таблица
setup_consumers
, потребитель global_instrumentation
.
Выходные таблицы поддержаны:
Нет.
Состояние конфигурации сервера:
mysql> SELECT * FROM setup_consumers; +---------------------------+---------+ | NAME | ENABLED | +---------------------------+---------+ | global_instrumentation | YES | | thread_instrumentation | NO | ... +---------------------------+---------+
В этой конфигурации инструментовка поддержана только для глобальных состояний. Инструментовка потоков отключена.
Дополнительные проверенные элементы установки, относительно предыдущей конфигурации:
Таблица
setup_consumers
, потребитель thread_instrumentation
.
setup_instruments
.setup_objects
.setup_timers
.Дополнительные выходные таблицы, относительно предыдущей конфигурации:
rwlock_instances
cond_instances
file_instances
users
hosts
accounts
socket_summary_by_event_name
file_summary_by_instance
file_summary_by_event_name
objects_summary_global_by_type
memory_summary_global_by_event_name
table_lock_waits_summary_by_table
table_io_waits_summary_by_index_usage
table_io_waits_summary_by_table
events_waits_summary_by_instance
events_waits_summary_global_by_event_name
events_stages_summary_global_by_event_name
events_statements_summary_global_by_event_name
events_transactions_summary_global_by_event_name
Состояние конфигурации сервера:
mysql> SELECT * FROM setup_consumers; +----------------------------------+---------+ | NAME | ENABLED | +----------------------------------+---------+ | global_instrumentation | YES | | thread_instrumentation | YES | | events_waits_current | NO | ... | events_stages_current | NO | ... | events_statements_current | NO | ... | events_transactions_current | NO | ... +----------------------------------+---------+
В этой конфигурации инструментовка поддержана глобально и для потоков. Никакие одиночные события не собраны в таблицах истории событий или текущих событиях.
Дополнительные проверенные элементы установки, относительно предыдущей конфигурации:
Таблица
setup_consumers
, потребители events_
, где xxx
_currentxxx
waits
, stages
,
statements
, transactions
.
setup_actors
.threads.instrumented
.Дополнительные выходные поддержанные таблицы, относительно предыдущей конфигурации:
events_
, где xxx
_summary_by_yyy
_by_event_namexxx
waits
, stages
, statements
,
transactions
, а yyy
thread
, user
,
host
, account
.
Состояние конфигурации сервера:
mysql> SELECT * FROM setup_consumers; +----------------------------------+---------+ | NAME | ENABLED | +----------------------------------+---------+ | global_instrumentation | YES | | thread_instrumentation | YES | | events_waits_current | YES | | events_waits_history | NO | | events_waits_history_long | NO | | events_stages_current | YES | | events_stages_history | NO | | events_stages_history_long | NO | | events_statements_current | YES | | events_statements_history | YES | | events_statements_history_long | NO | | events_transactions_current | YES | | events_transactions_history | YES | | events_transactions_history_long | NO | ... +----------------------------------+---------+
В этой конфигурации инструментовка поддержана глобально и для потока. Одиночные события собраны в таблице текущих событий, но не в таблицах истории событий.
Дополнительные проверенные элементы установки, относительно предыдущей конфигурации:
Потребители events_
,
где xxx
_historyxxx
waits
, stages
,
statements
, transactions
.
events_xxx
_history_long
,
где xxx
waits
, stages
,
statements
, transactions
.Дополнительные выходные поддержанные таблицы, относительно предыдущей конфигурации:
events_
,
где xxx
_currentxxx
is waits
, stages
,
statements
, transactions
.
Предыдущая конфигурация не собирает историю событий потому, что
потребители events_
и xxx
_historyevents_
отключены.
Эти потребители можно включить отдельно или вместе, чтобы собрать историю
событий для потока, глобально или обоими способами.xxx
_history_long
Эта конфигурация собирает историю событий для потока, но не глобально:
mysql> SELECT * FROM setup_consumers; +----------------------------------+---------+ | NAME | ENABLED | +----------------------------------+---------+ | global_instrumentation | YES | | thread_instrumentation | YES | | events_waits_current | YES | | events_waits_history | YES | | events_waits_history_long | NO | | events_stages_current | YES | | events_stages_history | YES | | events_stages_history_long | NO | | events_statements_current | YES | | events_statements_history | YES | | events_statements_history_long | NO | | events_transactions_current | YES | | events_transactions_history | YES | | events_transactions_history_long | NO | ... +----------------------------------+---------+
Таблицы истории событий для этой конфигурации:
events_
, где
xxx
_historyxxx
waits
, stages
,
statements
, transactions
.
Эта конфигурация собирает историю событий глобально, но не для потока:
mysql> SELECT * FROM setup_consumers; +----------------------------------+---------+ | NAME | ENABLED | +----------------------------------+---------+ | global_instrumentation | YES | | thread_instrumentation | YES | | events_waits_current | YES | | events_waits_history | NO | | events_waits_history_long | YES | | events_stages_current | YES | | events_stages_history | NO | | events_stages_history_long | YES | | events_statements_current | YES | | events_statements_history | YES | | events_statements_history_long | YES | | events_transactions_current | YES | | events_transactions_history | YES | | events_transactions_history_long | YES | ... +----------------------------------+---------+
Таблицы истории событий для этой конфигурации:
events_
, где
xxx
_history_longxxx
waits
, stages
,
statements
, transactions
.
Эта конфигурация собирает историю событий для потока и глобально:
mysql> SELECT * FROM setup_consumers; +----------------------------------+---------+ | NAME | ENABLED | +----------------------------------+---------+ | global_instrumentation | YES | | thread_instrumentation | YES | | events_waits_current | YES | | events_waits_history | YES | | events_waits_history_long | YES | | events_stages_current | YES | | events_stages_history | YES | | events_stages_history_long | YES | | events_statements_current | YES | | events_statements_history | YES | | events_statements_history_long | YES | | events_transactions_current | YES | | events_transactions_history | YES | | events_transactions_history_long | YES | ... +----------------------------------+---------+
Таблицы истории событий для этой конфигурации:
events_
, где
xxx
_historyxxx
waits
, stages
,
statements
, transactions
.
events_xxx
_history_long
, где
xxx
waits
, stages
,
statements
, transactions
.Имена, данные для того, чтобы фильтровать операции, могут быть столь определенными или общими как требуется. Чтобы указать на единственный инструмент или потребителя, определите его имя полностью:
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
';
Всегда возможно определить то, что инструментует Performance Schema,
проверяя setup_instruments
. Например, чтобы видеть, какие связанные с файлом события
инструментованы для механизма хранения InnoDB
,
используйте этот запрос:
mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'wait/io/file/innodb/%'; +--------------------------------------+---------+-------+ | NAME | ENABLED | TIMED | +--------------------------------------+---------+-------+ | wait/io/file/innodb/innodb_data_file | YES | YES | | wait/io/file/innodb/innodb_log_file | YES | YES | | wait/io/file/innodb/innodb_temp_file | YES | YES | +--------------------------------------+---------+-------+
Исчерпывающее описание того, что инструментовано, не дано в этой документации, по нескольким причинам:
То, что инструментовано, является кодом сервера. Изменения этого кода часто происходят, что также затрагивает набор инструментов.
setup_instruments
. Эта информация всегда современна для Вашей версии MySQL, а также
включает инструментовку для плагинов, которые Вы, возможно, установили,
не являющихся частью основного сервера.
Они могут использоваться автоматизированными инструментами.Предварительная фильтрация ограничивает, какая информация о событии
собрана и независима от любого особого пользователя. В отличие от этого,
постфильтрация выполнена отдельными пользователями с помощью запросов с
соответствующим 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.
Инструментальное имя состоит из последовательности компонентов, отделенных
'/'
Имена в качестве примера:
wait/io/file/myisam/log wait/io/file/mysys/charset wait/lock/table/sql/handler wait/synch/cond/mysys/COND_alarm wait/synch/cond/sql/BINLOG::update_cond wait/synch/mutex/mysys/BITMAP_mutex wait/synch/mutex/sql/LOCK_delete wait/synch/rwlock/sql/Query_cache_query::lock stage/sql/closing tables stage/sql/Sorting result statement/com/Execute statement/com/Query statement/sql/create_table statement/sql/lock_tables errors
У инструментального пространства имен есть подобная дереву структура. Компоненты инструментального имени слева направо обеспечивают прогрессию от более общего до более определенного. Число компонентов, которые имеет имя, зависит от типа инструмента.
Интерпретация данного компонента зависит от компонентов слева от этого.
Например, myisam
появляется в обоих из следующих имен, но
myisam
в первом имени связан с вводом/выводом файла, тогда как
во втором это связано с инструментом синхронизации:
wait/io/file/myisam/log wait/synch/cond/myisam/MI_SORT_INFO::cond
Инструментальные имена состоят из приставки со структурой, определенной
выполнением Performance Schema и суффиксом, определенным разработчиком,
осуществляющим инструментальный код. Высокоуровневый компонент
инструментальной приставки указывает на тип инструмента. Этот компонент также
определяет, который таймер событий в setup_timers
относится к
инструменту. Для части приставки инструментальных имен верхний уровень
указывает на тип инструмента.
Часть суффикса инструментальных имен прибывает непосредственно из кода для инструментов. Суффиксы могут включать уровни, такие как:
Название главного компонента (модуль сервера такой, как
myisam
, innodb
,
mysys
или sql
) или имя плагина.
XXX
(глобальная переменная) или
CCC
::MMM
(член MMM
класса CCC
). Примеры:
COND_thread_cache
, THR_LOCK_myisam
,
BINLOG::LOCK_index
.Высокоуровневые инструментальные компоненты
idle
: Инструментованный неактивный случай. У этого
инструмента нет никаких дальнейших компонентов.
error
: Инструментованный ошибочный случай. У этого
инструмента нет никаких дальнейших компонентов.memory
: Инструментованное событие памяти.stage
: Инструментованное событие этапа.statement
: Инструментованное событие запроса.transaction
: Инструментованное событие транзакции. У этого
инструмента нет никаких дальнейших компонентов.wait
: Инструментованное событие ожидания.Неактивные инструментальные компоненты
Инструмент idle
используется для неактивных событий, которые
Performance Schema производит как обсуждено в описании столбца
socket_instances.STATE
в
разделе 23.9.3.5.
Ошибочные инструментальные компоненты
Инструмент error
указывает, собрать ли информацию для ошибок
сервера и предупреждений. Этот инструмент включен по умолчанию. Столбец
TIMED
для строки error
в
setup_instruments
является неподходящим, потому что информация синхронизации не собрана.
Инструментальные компоненты памяти
Большинство инструментов памяти отключено по умолчанию и может быть
включено или отключено динамически, обновляя столбец
ENABLED
соответствующих инструментов в
setup_instruments
. У инструментов памяти есть названия формы
memory/
, где code_area
/instrument_name
code_area
такое значение, как
sql
или myisam
, а
instrument_name
инструментальная деталь.
Инструменты с приставкой memory/performance_schema/
показывают, сколько памяти выделено для внутренних буферов в Performance
Schema. Инструменты memory/performance_schema/
встроены, всегда
включаются, и не могут быть отключены при запуске или во время выполнения.
Встроенные инструменты памяти выведены на экран только в таблице
memory_summary_global_by_event_name
.
Инструментальные компоненты этапа
У инструментов этапа есть названия формы
stage/
, где code_area
/stage_name
code_area
такое значение, как
sql
или myisam
, а stage_name
указывает на этап обработки запроса, такой как Sorting result
или Sending data
. Этапы соответствуют статусам потока,
выведенным на экран SHOW
PROCESSLIST
или видимым в
INFORMATION_SCHEMA.PROCESSLIST
.
Инструментальные Компоненты запроса
statement/abstract/*
: Абстрактный инструмент для
операций запроса. Абстрактные инструменты используются во время ранних стадий
классификации запроса прежде, чем точный тип запроса будет известен, затем
изменены на более определенный инструмент запроса, когда тип известен. Для
описания этого процесса см.
раздел 23.9.6.
statement/com
: Инструментованная работа команды. У них есть
соответствие имен COM_xxx
(см. файлы mysql_com.h
и sql/sql_parse.cc
).
Например, инструменты statement/com/Connect
и
statement/com/Init DB
соответствуют командам
COM_CONNECT
и COM_INIT_DB
.statement/scheduler/event
: Единственный инструмент, чтобы
отследить все события, запущенные планировщиком событий. Этот инструмент
играет роль, когда запланированный случай начинает выполняться.statement/sp
: Инструментованная внутренняя инструкция
выполнена сохраненной программой. Например, инструменты
statement/sp/cfetch
и statement/sp/freturn
применяются для получения курсора и возврата из функции.statement/sql
: Инструментованная работа запроса SQL.
Например, инструменты statement/sql/create_db
и
statement/sql/select
используются для
CREATE DATABASE
и
SELECT
.Инструментальные компоненты ожидания
wait/io
Инструментованная работа ввода/вывода.
wait/io/file
Инструментованная работа ввода/вывода файла. Для файлов ожидание
является временем ожидания завершения работы файла (например, вызов
fwrite()
). Из-за кэширования физический ввод/вывод файла на
диске не может произойти в пределах этого требования.
wait/io/socket
Инструментованная работа сокета. У инструментов сокета есть названия формы
wait/io/socket/sql/
. У сервера
есть сокеты для каждого сетевого протокола, который он поддерживает. У
инструментов, связанных с сокетами TCP/IP или соединений файла сокета Unix,
есть значение socket_type
socket_type
server_tcpip_socket
или server_unix_socket
,
соответственно. Когда сокет слушания обнаруживает соединение, сервер передает
соединение с новым сокетом, которым управляет отдельный поток. У инструмента
для нового потока соединения есть значение
socket_type
client_connection
.
wait/io/table
Инструментованная табличная работа ввода/вывода. Они включают доступы на уровне строки к постоянным базовым или временным таблицам. Операции, которые затрагивают строки, являются получением, вставками, обновлениями и удалениями. Для представления ожидание связано с базовыми таблицами, на которые ссылается представление.
В отличие от большинства ожиданий, табличный ввод/вывод может включать
другое ожидание. Например, табличный ввод/вывод мог бы включать ввод/вывод
файла или операции памяти. Таким образом,
events_waits_current
для таблицы обычно имеет две строки.
Некоторые операции строки могли бы вызвать многократный табличный ввод/вывод. Например, вставка могла бы активировать триггер, который вызывает обновление.
wait/lock
Инструментованная работа блокировки.
wait/lock/table
Инструментованная блокировка таблицы.
wait/lock/metadata/sql/mdl
Инструментованные метаданные блокировки (отключены по умолчанию).
wait/synch
Инструментованный объект синхронизации. Для объектов синхронизации
время TIMER_WAIT
включает количество заблокированное времени,
потраченное пытаясь приобрести блокировку на объекте, если это было.
wait/synch/cond
Условие используется одним потоком, чтобы сигнализировать другим потокам, что что-то, чего они ждали, произошло. Если единственный поток ждал условия, он может проснуться и возобновить выполнение. Если несколько потоков ждали, они могут все проснуться и конкурировать за ресурс, которого они ждали.
wait/synch/mutex
Объект взаимного исключения используется, чтобы разрешить доступ к ресурсу (такому, как раздел выполнимого кода), препятствуя другим потокам получить доступ к ресурсу.
wait/synch/rwlock
Объект блокировки чтения-записи используется, чтобы блокировать определенную переменную для доступа, предотвращая ее использование другими потоками. Совместно используемая блокировка чтения может быть приобретена одновременно многими потоками. Исключительная блокировка записи может быть приобретена только одним потоком за один раз.
wait/synch/sxlock
Совместно используемо-исключительная (SX) блокировка тип объекта блокировки rwlock, который обеспечивает доступ на запись к общему ресурсу, разрешая непоследовательные чтения другим потокам.
Есть несколько переменных состояния, связанных с Performance Schema:
mysql> SHOW STATUS LIKE 'perf%'; +-----------------------------------------------+-------+ | Variable_name | Value | +-----------------------------------------------+-------+ | Performance_schema_accounts_lost | 0 | | Performance_schema_cond_classes_lost | 0 | | Performance_schema_cond_instances_lost | 0 | | Performance_schema_digest_lost | 0 | | Performance_schema_file_classes_lost | 0 | | Performance_schema_file_handles_lost | 0 | | Performance_schema_file_instances_lost | 0 | | Performance_schema_hosts_lost | 0 | | Performance_schema_locker_lost | 0 | | Performance_schema_memory_classes_lost | 0 | | Performance_schema_metadata_lock_lost | 0 | | Performance_schema_mutex_classes_lost | 0 | | Performance_schema_mutex_instances_lost | 0 | | Performance_schema_nested_statement_lost | 0 | | Performance_schema_program_lost | 0 | | Performance_schema_rwlock_classes_lost | 0 | | Performance_schema_rwlock_instances_lost | 0 | | Performance_schema_session_connect_attrs_lost | 0 | | Performance_schema_socket_classes_lost | 0 | | Performance_schema_socket_instances_lost | 0 | | Performance_schema_stage_classes_lost | 0 | | Performance_schema_statement_classes_lost | 0 | | Performance_schema_table_handles_lost | 0 | | Performance_schema_table_instances_lost | 0 | | Performance_schema_thread_classes_lost | 0 | | Performance_schema_thread_instances_lost | 0 | | Performance_schema_users_lost | 0 | +-----------------------------------------------+-------+
Переменные состояния Performance Schema предоставляют информацию об инструментовке, которая не могла быть загружена или создана из-за ограничений памяти. У названий этих переменных есть несколько форм:
Performance_schema_
указывает сколько инструментов типа xxx
_classes_lost
xxx
не могли быть загружены.
Performance_schema_xxx
_instances_lost
указывает, сколько экземпляров объекта xxx
не могло быть создано.Performance_schema_xxx
_handles_lost
указывает, сколько экземпляров объекта xxx
не могло быть открыто.Performance_schema_locker_lost
указывает, сколько событий
потеряны или не зарегистрированы.Например, если mutex инструментован в источнике сервера, но сервер не
может выделить память для инструментовки во время выполнения, это увеличивает
Performance_schema_mutex_classes_lost
. Здесь mutex все еще
функционирует как объект синхронизации (то есть, сервер продолжает
функционировать обычно), но характеристики для этого не будут собраны. Если
инструмент может быть выделен, он может использоваться для того, чтобы
инициализировать инструментованные mutex случаи. Для единичного mutex, такого
как глобальный mutex, будет только один случай. У других mutex есть случай на
соединение или страницу в различных кэшах и буферах данных, таким образом,
число случаев изменяется в течение долгого времени. Увеличение максимального
количества соединений или максимального размера некоторых буферов увеличит
максимальное количество случаев, которые могли бы быть выделены сразу. Если
сервер не может создать инструментованный mutex случай, он увеличивает
Performance_schema_mutex_instances_lost
.
Предположите, что следующие условия выполнены:
Сервер был запущен с опцией
--performance_schema_max_mutex_classes=200
и таким образом имеет пространство для 200 инструментов mutex.
plugin_a
содержит 40 инструментов mutex.plugin_b
содержит 20 инструментов mutex.Сервер выделяет mutex инструменты для плагинов в зависимости от того, в скольких они нуждаются и сколько доступно, как иллюстрировано следующей последовательностью запросов:
INSTALL PLUGIN plugin_a
Сервер теперь имеет 150+40 = 190 mutex.
UNINSTALL PLUGIN plugin_a;
У сервера все еще есть 190 инструментов. Все исторические данные, произведенные сменным кодом, являются все еще доступными, но новые события для инструментов не собраны.
INSTALL PLUGIN plugin_a;
Сервер обнаруживает, что эти 40 инструментов уже определены, таким образом, никакие новые инструменты не создаются, и ранее назначенные внутренние буферы памяти снова использованы. У сервера все еще есть 190 инструментов.
INSTALL PLUGIN plugin_b;
Сервер имеет пространство для 200-190 = 10 инструментов (в этом случае
классы mutex) и видит, что плагин содержит 20 новых инструментов. 10
инструментов загружены, а 10 потеряны.
Performance_schema_mutex_classes_lost
указывает на
число потерянных инструментов:
mysql> SHOW STATUS LIKE "perf%mutex_classes_lost"; +---------------------------------------+-------+ | Variable_name | Value | +---------------------------------------+-------+ | Performance_schema_mutex_classes_lost | 10 | +---------------------------------------+-------+ 1 row in set (0.10 sec)
Инструментовка все еще работает и собирает (частичные) данные для
plugin_b
.
Когда сервер не может создать mutex инструмент, эти результаты происходят:
Никакая строка для инструмента не вставлена в
setup_instruments
.
Performance_schema_mutex_classes_lost
растет на 1.Performance_schema_mutex_instances_lost
не изменяется.
Когда инструмент mutex не создается, он не может использоваться, чтобы
создать инструментованные случаи mutex позже.Этот пример относится ко всем типам инструментов, не только mutex.
Значение
Performance_schema_mutex_classes_lost
больше 0
может произойти в двух случаях:
Чтобы сохранить несколько байтов памяти, Вы запускаете сервер с
--performance_schema_max_mutex_classes=
,
где N
N
меньше, чем значение по умолчанию. Значение по
умолчанию выбрано, чтобы быть достаточным, чтобы загрузить все плагины,
обеспеченные в дистрибутиве MySQL, но это может быть уменьшено, если
некоторые плагины никогда не загружаются. Например, Вы могли бы хотеть не
загружать некоторые из механизмов хранения.
performance_schema_max_mutex_classes
.
Если у сервера недостаточно ресурсов для инструментов плагина, и Вы
явно не выделяете больше, используя
--performance_schema_max_mutex_classes=
,
загрузка плагина приводит к проблемам.N
Если значение, выбранное для
performance_schema_max_mutex_classes
является слишком маленьким,
ни о какой ошибке не сообщают в журнале ошибок и нет никакого отказа во время
выполнения. Однако, контент таблиц в performance_schema
пропустит события. Переменная состояния
Performance_schema_mutex_classes_lost
единственный видимый
знак указать, что некоторые события были удалены внутренне из-за
отказа создать инструменты.
Если инструмент не потерян, он известен Performance Schema
и используется, инструментуя случаи. Например,
wait/synch/mutex/sql/LOCK_delete
имя mutex инструмента в
setup_instruments
. Этот единственный инструмент используется, создавая mutex в коде (в
THD::LOCK_delete
), однако, много случаев mutex необходимы, когда
сервер работает. В этом случае LOCK_delete
mutex для соединения
(THD
), так что, если у сервера есть 1000 соединений, есть 1000
потоков и 1000 инструментованных случаев LOCK_delete
mutex
(THD::LOCK_delete
).
Если сервер не имеет пространства для инструментованного mutexes всех
этих 1000, некоторые mutex создаются с инструментовкой, а некоторые создаются
без инструментовки. Если сервер может создать только 800 случаев, 200 случаев
потеряны. Сервер продолжает работать, но увеличивает
Performance_schema_mutex_instances_lost
на 200, чтобы указать, что
случаи не могли быть созданы.
Значение
Performance_schema_mutex_instances_lost
больше 0
может произойти, когда код инициализирует больше mutex во время выполнения,
чем было выделено для
--performance_schema_max_mutex_instances=
.
N
-Нижняя строка это если
SHOW STATUS LIKE 'perf%'
говорит, что ничто не было потеряно (все значения - ноль), Исполнительные
данные точны и могут быть использованы. Если что-то было потеряно, данные
неполные, и Performance Schema не могла сделать запись всех данных.
В этом случае переменная Performance_schema_
указывает на проблемную область.xxx
_lost
Могло бы быть уместно в некоторых случаях вызвать преднамеренный инструментальный сбой. Например, если Вы не заботитесь о характеристиках ввода/вывода файла, Вы можете запустить сервер со всеми параметрами Performance Schema, связанных с вводом/выводом файла, установленными в 0. Никакая память не будет выделена для связанных с файлом классов, случаев или дескрипторов, и все события файла будут потеряны.
Надо использовать SHOW ENGINE
PERFORMANCE_SCHEMA STATUS
, чтобы просмотреть внутреннюю работу
кода Performance Schema:
mysql> SHOW ENGINE PERFORMANCE_SCHEMA STATUS\G ... *************************** 3. row *************************** Type: performance_schema Name: events_waits_history.size Status: 76 *************************** 4. row *************************** Type: performance_schema Name: events_waits_history.count Status: 10000 *************************** 5. row *************************** Type: performance_schema Name: events_waits_history.memory Status: 760000 ... *************************** 57. row *************************** Type: performance_schema Name: performance_schema.memory Status: 26459600 ...
Это запрос предназначен, чтобы помочь DBA понять эффекты, которые различные опции Performance Schema оказывают на требования к памяти. Для описания полевых значений см. раздел 14.7.5.15.
Для табличного случая ввода/вывода обычно есть две строки в
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
. В этом пункте, пока начинается следующий
вспомогательный случай, табличный ввод/вывод также новее
ожидания любого вида.
Сервер MySQL способен к поддержанию информации об обзоре запроса. Процесс переваривания преобразовывает запрос SQL к нормализованной форме и вычисляет значение хеша для результата. Нормализация разрешает запросы, которые подобны, сгруппировать и суммировать, чтобы выставить информацию о типах запросов, которые выполняет сервер и то, как часто они происходят. Этот раздел описывает, как нормализация запросы происходит и как это может быть полезно.
Переваривание происходит на уровне SQL независимо от того, доступна ли Performance Schema, чтобы у других функций сервера, таких как плагины перезаписи запроса был доступ к обзорам запроса.
В Performance Schema запрос вовлекает эти компоненты:
Потребитель statement_digest
в
setup_consumers
управляет, поддерживает ли Performance Schema информацию об обзоре.
events_statements_current
,
events_statements_history
и
events_statements_history_long
) имеют столбцы, которые содержат
обзоры и соответствующие значения хеша обзора:
DIGEST_TEXT
текст нормализованного обзора запроса.
DIGEST
значение хеша MD5 обзора.Максимальное пространство, доступное для вычисления обзора, составляет
1024 байта по умолчанию. Это значение может быть изменено при запуске
сервера, устанавливая переменную
performance_schema_max_digest_length
.
SQL_TEXT
,
который содержит оригинальный запрос SQL. Максимальное пространство,
доступное для отображнеия запроса, составляет 1024 байта по умолчанию. Это
значение может быть изменено при запуске сервера, устанавливая переменную
performance_schema_max_sql_text_length
.
events_statements_summary_by_digest
предоставляет соединенную
информацию об обзоре запроса.Нормализация преобразовывает текст запроса к более стандартизированному строковому представлению обзора, которое сохраняет структуру общего утверждения, удаляя информацию, не важную для структуры:
Сохранены идентификаторы объекта, такие как имена баз данных и таблиц.
Рассмотрите эти запросы:
SELECT * FROM orders WHERE customer_id=10 AND quantity > 20 SELECT * FROM orders WHERE customer_id = 20 AND quantity > 100
Чтобы нормализовать эти запросы, Performance Schema
заменяет значения данных ?
и корректирует пробелы.
Оба запроса приводят к той же самой нормализованной форме и таким
образом считаются подобными:
SELECT * FROM orders WHERE customer_id = ? AND quantity > ?
Нормализованный запрос содержит меньше информации, но является все еще представительным для оригинального запроса. У других подобных запросов, у которых есть различные сравнительные значения, есть та же самая нормализованная форма.
Теперь рассмотрите эти запросы:
SELECT * FROM customers WHERE customer_id = 1000 SELECT * FROM orders WHERE customer_id = 1000
В этом случае запросы не подобны. Идентификаторы объекта отличаются, таким образом, запросы приводят к различным нормализованным формам:
SELECT * FROM customers WHERE customer_id = ? SELECT * FROM orders WHERE customer_id = ?
Если нормализация производит запрос, который превышает пространство, доступное в буфере обзора, текст кончается с .... Длинные запросы, которые отличаются только по части, которая происходит после ..., как полагают, являются подобными. Рассмотрите эти запросы:
SELECT * FROM mytable WHERE cola = 10 AND colb = 20 SELECT * FROM mytable WHERE cola = 10 AND colc = 20
Если сокращение было правильным, после AND
у обоих запросов была бы эта нормализованная форма:
SELECT * FROM mytable WHERE cola = ? AND ...
В этом случае различие во втором имени столбца потеряно, и оба запросы считаются подобными.
Для каждого нормализованного запроса Performance Schema
вычисляет значение обзора хеша и хранит запрос и его значение хеша MD5 в
столбцах DIGEST_TEXT
и DIGEST
таблиц событий
запросов (
events_statements_current
,
events_statements_history
и
events_statements_history_long
). Кроме того, информация для
запросов с теми же самыми значениями SCHEMA_NAME
и
DIGEST
соединена в таблице
events_statements_summary_by_digest
. Performance Schema использует
значения хеша MD5, потому что они быстры, чтобы вычислить и иметь
благоприятное статистическое распределение,
которое минимизирует столкновения.
Сводная таблица обзора запросов обеспечивает профиль запросов, выполненных сервером. Это показывает, какие виды запросов приложение выполняет и как часто. Разработчик приложений может использовать эту информацию вместе с другой информацией в таблице, чтобы оценить технические характеристики приложения. Например, столбцы таблицы, которые показывают время ожидания, время блокировки или использование индекса, могут выделить типы запросов, которые неэффективны. Это дает понимание разработчика, каким частям приложения необходимо уделять внимание.
events_statements_summary_by_digest
имеет фиксированный размер,
так что, когда это становится полным, запросы, которые имеют
SCHEMA_NAME
и DIGEST
не соответствующие
существующим значениям в таблице, сгруппированы в специальной строке с
SCHEMA_NAME
и DIGEST
NULL
.
Это разрешает всем запросым быть посчитанными. Однако, если специальная
строка составляет существенный процент выполненных запросов, могло бы быть
желательно увеличить размер сводной таблицы, устанавливая переменную
performance_schema_digests_size
к большему значению при запуске
сервера. Если не задано значение
performance_schema_digests_size
, Performance Schema использует
значение при запуске.
Переменная
performance_schema_max_digest_length
определяет максимальное
количество байтов, доступных в буфере обзора для вычисления обзора.
Однако, длина отображения обзоров может быть больше, чем доступный размер
буфера из-за кодирования компонентов запросы, таких как ключевые слова и
буквальные значения в буфере обзора. Следовательно, значения, выбранные из
столбца DIGEST_TEXT
таблиц событий запросов, может казаться,
превышает
performance_schema_max_digest_length
.
Для приложений, которые производят очень длинные запросы, которые
отличаются только в конце, увеличение
performance_schema_max_digest_length
позволяет вычисление
обзоров, которые отличают запросы, которые иначе соединились бы к тому же
самому обзору. Наоборот, уменьшение
performance_schema_max_digest_length
заставляет сервер посвящать меньше памяти хранению обзора, но увеличивает
вероятность более длинных запросов, соединяющихся к тому же самому обзору.
Администраторы должны иметь в виду, что большие значения приводят к
соответственно увеличенным требованиям к памяти, особенно для рабочих
нагрузок, которые вовлекают большие количества одновременных сеансов
(
performance_schema_max_digest_length
байт выделено на сеанс).
Чтобы оценить объем памяти, используемый для хранения запроса SQL
и вычисления обзора, используйте SHOW ENGINE PERFORMANCE_SCHEMA STATUS
или эти инструменты:
mysql> SELECT NAME FROM setup_instruments WHERE NAME LIKE '%.sqltext'; +------------------------------------------------------------------+ | NAME | +------------------------------------------------------------------+ | memory/performance_schema/events_statements_history.sqltext | | memory/performance_schema/events_statements_current.sqltext | | memory/performance_schema/events_statements_history_long.sqltext | +------------------------------------------------------------------+ mysql> SELECT NAME FROM setup_instruments WHERE NAME LIKE 'memory/performance_schema/%.tokens'; +----------------------------------------------------------------------+ | NAME | +----------------------------------------------------------------------+ | memory/performance_schema/events_statements_history.tokens | | memory/performance_schema/events_statements_current.tokens | | memory/performance_schema/events_statements_summary_by_digest.tokens | | memory/performance_schema/events_statements_history_long.tokens | +----------------------------------------------------------------------+
Название базы данных performance_schema
в
нижнем регистре, как названия таблиц в пределах этого. Запросы должны
определить имена в нижнем регистре.
Много таблиц в performance_schema
только для чтения и не могут быть изменены:
mysql> TRUNCATE TABLE setup_instruments; ERROR 1683 (HY000): Invalid performance_schema usage.
У некоторых из таблиц установки есть столбцы, которые могут быть изменены,
чтобы затронуть работу Performance Schema. Некоторые также разрешают строкам
быть вставленными или удаленными. Усечение разрешено для очистки собранных
событий, таким образом, TRUNCATE TABLE
может использоваться на таблицах, содержащих эти виды информации,
такие как таблицы, названные с приставкой events_waits_
.
Сводные таблицы могут быть усечены с
TRUNCATE TABLE
.
Вообще, эффект состоит в том, чтобы сбросить сводные столбцы к 0 или
NULL
, а не удалить строки. Это позволяет очистить собранные
значения. Это могло бы быть полезно, например, после того, как Вы произвели
изменение конфигурации во время выполнения. Исключения к этому поведению
усечения отмечены в отдельных разделах сводной таблицы.
Привилегии что касается других баз данных и таблиц:
Чтобы получать данные из таблиц performance_schema
,
Вы должны иметь привилегию SELECT
.
UPDATE
.DROP
.
Таблицы в performance_schema
могут быть
сгруппированы следующим образом:
Таблицы установки. Эти таблицы используются, чтобы сконфигурировать и вывести на экран контролирующие характеристики.
events_waits_current
содержит новый случай для каждого потока. Другие подобные таблицы
содержат текущие события на разных уровнях иерархии событий:
events_stages_current
для событий этапа,
events_statements_current
для событий запросов и
events_transactions_current
для операционных событий.events_waits_history
содержит новые 10 событий для потока.
events_waits_history_long
содержит новые 10000 событий. Другие
подобные таблицы существуют для этапа, запросов и операционных историй.
Чтобы изменить размеры таблиц истории, установите соответствующие
системные переменные при запуске сервера. Например, чтобы установить размеры
таблиц истории ожидания событий, установите
performance_schema_events_waits_history_size
и
performance_schema_events_waits_history_long_size
.
Следующая таблица приводит каждую таблицу 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 | Как системные переменные были последний раз установлены |
Таблицы установки предоставляют информацию о текущей инструментовке и
позволяют контролирующей конфигурации быть измененной. Поэтому некоторые
столбцы в этих таблицах могут быть изменены, если Вы имеете привилегию
UPDATE
.
Использование таблиц, а не отдельных переменных для информации об установке обеспечивает высокую степень гибкости в изменении конфигурации Performance Schema. Например, Вы можете использовать единственный запрос со стандартным синтаксисом SQL, чтобы произвести многократные одновременные изменения конфигурации.
Эти таблицы установки доступны:
setup_actors
: Как инициализировать контроль для новых потоков переднего плана.
setup_consumers
: Места назначения, в которые информацию о событии можно послать.setup_instruments
: Классы инструментованных объектов, для которых могут
быть собраны события.setup_objects
:
Какие объекты должны быть проверены.setup_timers
:
Текущий таймер событий.Таблица setup_actors
содержит информацию, которая определяет, позволить ли контролировать и
журналировать исторические события для новых потоков сервера переднего плана
(потоки, связанные с соединениями клиента). У этой таблицы есть максимальный
размер 100 строк по умолчанию. Чтобы изменить табличный размер,
измените системную переменную
performance_schema_setup_actors_size
при запуске сервера.
Для каждого нового потока переднего плана Performance Schema
соответствует пользователю и узлу в строке таблицы
setup_actors
.
Если строка этой таблицы соответствует, значения ее столбцов
ENABLED
и HISTORY
используются, чтобы установить
столбцы INSTRUMENTED
и HISTORY
, соответственно,
в строках таблицы threads
для потока. Это позволяет управлять инструментовкой и журналированием
исторических событий, которое будет применено выборочно для узла,
пользователя или учетной записи (комбинация узла и пользователя). Если нет
соответствия, INSTRUMENTED
и HISTORY
для потока установлены в NO
.
Для фоновых потоков нет никакого связанного пользователя.
INSTRUMENTED
и HISTORY
YES
по умолчанию и setup_actors
не проверяется.
Начальное содержание
setup_actors
соответствует любой комбинации пользователя и узла,
таким образом контроль и сбор исторических событий включены по умолчанию для
всех потоков переднего плана:
mysql> SELECT * FROM setup_actors; +------+------+------+---------+---------+ | HOST | USER | ROLE | ENABLED | HISTORY | +------+------+------+---------+---------+ | % | % | % | YES | YES | +------+------+------+---------+---------+
Модификации setup_actors
вступают в силу только при создании потоков переднего плана
после модификации, на существующие потоки изменения не влияют.
Чтобы затронуть существующие потоки, измените столбцы
INSTRUMENTED
и HISTORY
строк таблицы
threads
.
У таблицы setup_actors
есть эти столбцы:
HOST
Имя хоста. Это должно быть буквальным именем или
'%'
означает любой хост.
USER
Имя пользователя. Это должно быть буквальным именем или
'%'
означает любой пользователь.
ROLE
Не используется.
ENABLED
Включить ли инструментовку для потоков переднего плана, соответствующих
строке. Значения YES
или NO
.
HISTORY
Зарегистрировать ли исторические события для потоков переднего плана,
соответствующих строке. Значения YES
или NO
.
У таблицы setup_actors
есть эти индексы:
Первичный ключ на (HOST
, USER
,
ROLE
).
TRUNCATE TABLE
разрешен для setup_actors
. Удаляет строки.
Таблица setup_consumers
приводит типы потребителей, для которых может быть сохранена
информация о событии и которые включены:
mysql> SELECT * FROM setup_consumers; +----------------------------------+---------+ | NAME | ENABLED | +----------------------------------+---------+ | events_stages_current | NO | | events_stages_history | NO | | events_stages_history_long | NO | | events_statements_current | YES | | events_statements_history | YES | | events_statements_history_long | NO | | events_transactions_current | NO | | events_transactions_history | NO | | events_transactions_history_long | NO | | events_waits_current | NO | | events_waits_history | NO | | events_waits_history_long | NO | | global_instrumentation | YES | | thread_instrumentation | YES | | statements_digest | YES | +----------------------------------+---------+
Модификации
setup_consumers
действуют немедленно.
У таблицы
setup_consumers
есть эти столбцы:
NAME
Потребительское имя.
ENABLED
Включен ли потребитель. Значение YES
или NO
.
Этот столбец может быть изменен. Если Вы отключаете потребителя, сервер не
тратит время на добавление информацию о событии к этому.
У setup_consumers
есть эти индексы:
Первичный ключ на (NAME
).
TRUNCATE TABLE
не разрешен для
setup_consumers
.
setup_instruments
приводит классы инструментованных объектов, для которых могут
быть собраны события:
mysql> SELECT * FROM setup_instruments; +---------------------------------------------------+---------+-------+ | NAME | ENABLED | TIMED | +---------------------------------------------------+---------+-------+ ... | wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES | | wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES | | wait/synch/mutex/sql/LOCK_lock_db | YES | YES | | wait/synch/mutex/sql/LOCK_manager | YES | YES | ... | wait/synch/rwlock/sql/LOCK_grant | YES | YES | | wait/synch/rwlock/sql/LOGGER::LOCK_logger | YES | YES | | wait/synch/rwlock/sql/LOCK_sys_init_connect | YES | YES | | wait/synch/rwlock/sql/LOCK_sys_init_slave | YES | YES | ... | wait/io/file/sql/binlog | YES | YES | | wait/io/file/sql/binlog_index | YES | YES | | wait/io/file/sql/casetest | YES | YES | | wait/io/file/sql/dbopt | YES | YES | ...
Каждый инструмент, добавленный к исходному коду, обеспечивает строку
в этой таблице, даже когда инструментованный код не выполнен. Когда
инструмент включен и запущен, инструментованные случаи создаются, которые
видимы в таблицах *_instances
.
Для некоторых инструментов модификации эффективны только при запуске сервера, изменение их во времени выполнения не имеет никакого эффекта. Это затрагивает прежде всего mutex, условия и rwlocks в сервере, хотя могут быть другие инструменты, для которых это истина. Для большинства изменения вступают в силу сразу.
У setup_instruments
есть эти столбцы:
NAME
Инструментальное имя. Инструментальные имена могут иметь много частей
и сформировать иерархию, как обсуждено в
разделе 23.4.
События, произведенные из выполнения инструмента, имеют
EVENT_NAME
, которое взято от инструментального значения
NAME
. У событий действительно нет name,
но это обеспечивает способ связать события с инструментами.
ENABLED
Включен ли инструмент. Значение YES
или NO
.
Этот столбец может быть изменен.
Отключенный инструмент не производит событий.
TIMED
Рассчитан ли инструмент. Этот столбец может быть изменен.
Для инструментов памяти столбец TIMED
в
setup_instruments
проигнорирован, потому что операции памяти не рассчитаны.
Если включенный инструмент не рассчитан, инструментальный код включен,
но таймер нет. События, произведенные инструментом, имеют NULL
для TIMER_START
, TIMER_END
и
TIMER_WAIT
. Это в свою очередь заставляет те значения быть
проигнорированными, вычисляя сумму, минимум, максимум и средние временные
оценки в сводных таблицах.
У setup_instruments
есть эти индексы:
Первичный ключ на (NAME
).
TRUNCATE TABLE
не
разрешен для
setup_instruments
.
setup_objects
управляет, контролирует ли Performance Schema особые объекты. У этой таблицы
есть максимальный размер 100 строк по умолчанию. Чтобы изменить табличный
размер, измените переменную
performance_schema_setup_objects_size
при запуске сервера.
Начальное содержание
setup_objects
похоже на это:
mysql> SELECT * FROM setup_objects; +-------------+--------------------+-------------+---------+-------+ | OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED | +-------------+--------------------+-------------+---------+-------+ | EVENT | mysql | % | NO | NO | | EVENT | performance_schema | % | NO | NO | | EVENT | information_schema | % | NO | NO | | EVENT | % | % | YES | YES | | FUNCTION | mysql | % | NO | NO | | FUNCTION | performance_schema | % | NO | NO | | FUNCTION | information_schema | % | NO | NO | | FUNCTION | % | % | YES | YES | | PROCEDURE | mysql | % | NO | NO | | PROCEDURE | performance_schema | % | NO | NO | | PROCEDURE | information_schema | % | NO | NO | | PROCEDURE | % | % | YES | YES | | TABLE | mysql | % | NO | NO | | TABLE | performance_schema | % | NO | NO | | TABLE | information_schema | % | NO | NO | | TABLE | % | % | YES | YES | | TRIGGER | mysql | % | NO | NO | | TRIGGER | performance_schema | % | NO | NO | | TRIGGER | information_schema | % | NO | NO | | TRIGGER | % | % | YES | YES | +-------------+--------------------+-------------+---------+-------+
Модификации действуют немедленно.
Для типов объекта, перечисленных в
setup_objects
,
Performance Schema использует таблицу для того, как контролировать их.
Соответствие лбъектов основано на столбцах OBJECT_SCHEMA
и
OBJECT_NAME
. Объекты, которые не идут ни в какое
сравнение, не проверены.
Эффект конфигурации объекта по умолчанию состоит в том, чтобы
инструментовать все таблицы кроме в
mysql
, INFORMATION_SCHEMA
и
performance_schema
. Таблицы в INFORMATION_SCHEMA
не инструментована независимо от содержания
setup_objects
.
Строка information_schema.%
просто делает это значение явным.
Когда Performance Schema checks проверяет на соответствие
setup_objects
,
это пытается найти более определенные соответствия сначала. Например, с
таблицей db1.t1
, это ищет совпадение для
'db1'
и 't1'
, потом для
'db1'
и '%'
, потом для
'%'
и '%'
. Порядок, в котором соответствие
происходит таков, потому что различные строки
setup_objects
могут иметь отличающиеся ENABLED
и TIMED
.
Строки могут быть вставлены или удалены из
setup_objects
пользователями с привилегиями
INSERT
или DELETE
на таблице. Для существующих строк могут быть изменены только
столбцы ENABLED
и TIMED
пользователями с
привилегией UPDATE
.
У setup_objects
есть эти столбцы:
OBJECT_TYPE
Тип объекта для инструментовки. Значение одно из
'EVENT'
(событие Event Scheduler),
'FUNCTION'
(сохраненная функция),
'PROCEDURE'
(хранимая процедура), 'TABLE'
(базовая
таблица) или 'TRIGGER'
(триггер).
TABLE
фильтрует табличные события ввода/вывода
(инструмент wait/io/table/sql/handler
) и события блокировки
таблицы (wait/lock/table/sql/handler
).
OBJECT_SCHEMA
Схема, которая содержит объект. Это должно быть буквальным именем или
'%'
для любой схемы.
OBJECT_NAME
Название инструментованного объекта. Это должно быть буквальным именем
или '%'
для любого объекта.
ENABLED
Инструментованы ли события для объекта. Значение YES
или
NO
. Этот столбец может быть изменен.
TIMED
Рассчитаны ли события для объекта. Этот столбец может быть изменен.
У setup_objects
есть эти индексы:
Индекс на (OBJECT_TYPE
,
OBJECT_SCHEMA
, OBJECT_NAME
).
TRUNCATE TABLE
разрешен для setup_objects
. Это удаляет строки.
setup_timers
показывает в настоящее время выбираемые таймеры событий:
mysql> SELECT * FROM setup_timers; +-------------+-------------+ | NAME | TIMER_NAME | +-------------+-------------+ | idle | MICROSECOND | | wait | CYCLE | | stage | NANOSECOND | | statement | NANOSECOND | | transaction | NANOSECOND | +-------------+-------------+
setup_timers.TIMER_NAME
может быть изменено, чтобы выбрать
иной таймер. Значение может быть любым из значений в столбце
performance_timers.TIMER_NAME
.
Изменения в setup_timers
действуют немедленно. События, уже происходящие, могут
использовать оригинальный таймер в начале и новый таймер в конце. Чтобы
избежать непредсказуемых результатов после того, как Вы производите изменения
таймера, надо использовать
TRUNCATE TABLE
для сброса
статистики Performance Schema.
У setup_timers
есть эти столбцы:
NAME
Тип инструмента, для которого таймер используется.
TIMER_NAME
Таймер, который относится к инструментальному типу. Этот столбец может быть изменен.
У setup_timers
есть эти индексы:
Первичный ключ на (NAME
).
TRUNCATE TABLE
не
позволен для setup_timers
.
Таблицы случая документируют, какие типы объектов инструментованы. Они обеспечивают имена событий и примечания или информацию о статусе:
cond_instances
: Синхронизация условия.
file_instances
: Случаи файла.mutex_instances
: Синхронизация Mutex.rwlock_instances
: Синхронизация блокировки.socket_instances
: Активные соединения.Эти таблицы приводят инструментованные объекты синхронизации, файлы и
соединения. Есть три типа объектов синхронизации: cond
,
mutex
и rwlock
. Каждая таблица случая имеет
столбцы EVENT_NAME
или NAME
, чтобы указать на
инструмент, связанный с каждой строкой. Инструментальные имена могут иметь
много частей и сформировать иерархию, как обсуждено в
разделе 23.4.
Столбцы mutex_instances.LOCKED_BY_THREAD_ID
и
rwlock_instances.WRITE_LOCKED_BY_THREAD_ID
чрезвычайно важны для
исследования исполнительных узких мест или тупиков. Для примеров того, как
использовать их с этой целью см.
раздел 23.16.
cond_instances
приводит все условия, замеченные Performance Schema в то время, как сервер
выполняется. Условие это механизм синхронизации, используемый в коде, чтобы
сигнализировать, что определенное событие произошло, чтобы поток, ждущий
этого условия, мог возобновить работу.
Когда поток ждет чего-то, имя условия это признак того, чего ждет поток, но нет никакого непосредственного способа сказать, который другой поток или потоки вызовет условие.
У cond_instances
есть эти столбцы:
NAME
Инструментальное имя, связанное с условием.
OBJECT_INSTANCE_BEGIN
Адрес в памяти об инструментованном условии.
У cond_instances
есть эти индексы:
Первичный ключ на (OBJECT_INSTANCE_BEGIN
).
NAME
).TRUNCATE TABLE
не
позволен для cond_instances
.
file_instances
приводит все файлы, замеченные Performance Schema, запуская инструментовку
ввода/вывода файла. Если файл на диске никогда не открывался, его не будет в
file_instances
.
Когда файл удален с диска, он также удален из
file_instances
.
У file_instances
есть эти столбцы:
FILE_NAME
Имя файла.
EVENT_NAME
Инструментальное имя, связанное с файлом.
OPEN_COUNT
Количество открытых дескрипторов на файле. Если файл был открыт и затем
закрыт, он был открыт 1 раз, но OPEN_COUNT
будет 0. Чтобы
перечислить все файлы, в настоящее время открываемые сервером, надо
использовать WHERE OPEN_COUNT > 0
.
У file_instances
есть эти индексы:
Первичный ключ на (FILE_NAME
).
EVENT_NAME
).TRUNCATE TABLE
не позволен для
file_instances
.
mutex_instances
приводит все mutex, замеченные Performance Schema в то время, как сервер
выполняет. mutex это механизм синхронизации, используемый в коде, чтобы
провести в жизнь только тот поток, который в установленный срок может иметь
доступ к некоторому общему ресурсу. Ресурс, как говорят, при этом
является защищенным mutex.
Когда два потока в сервере (например, два пользовательских сеанса, выполняющие запрос одновременно), действительно должны будут получить доступ к тому же самому ресурсу (файлу, буферу или некоторой части данных), эти два потока конкурируют друг против друга так, чтобы первый запрос, который получит блокировку на mutex, заставил другой запрос ждать, пока первый не будет сделан и отпирает mutex.
Это потенциально узкое место, именуемое "критический раздел". Проблема в том, что много потоков вынуждены проходить его строго последовательно и по одному.
У mutex_instances
есть эти столбцы:
NAME
Инструментальное имя, связанное с mutex.
OBJECT_INSTANCE_BEGIN
Адрес в памяти об инструментованном mutex.
LOCKED_BY_THREAD_ID
Когда потоку в настоящее время блокировали mutex,
LOCKED_BY_THREAD_ID
THREAD_ID
потока блокировки, иначе это NULL
.
У mutex_instances
есть эти индексы:
Первичный ключ на (OBJECT_INSTANCE_BEGIN
).
NAME
).LOCKED_BY_THREAD_ID
).TRUNCATE TABLE
не
позволен для mutex_instances
.
Для каждого mutex, инструментованного в коде, Performance Schema предоставляет следующую информацию.
Таблица
setup_instruments
приводит название пункта инструментовки, с
приставкой wait/synch/mutex/
.
mutex_instances
.
Столбец OBJECT_INSTANCE_BEGIN
свойство, которое
уникально идентифицирует mutex.events_waits_current
показывает строку для этого потока, указывая, что он ждет mutex
(в столбце EVENT_NAME
) и указание, какой mutex ждут (в столбце
OBJECT_INSTANCE_BEGIN
).
events_waits_current
показывает, что ожидание mutex завершено (в
столбцах TIMER_END
и TIMER_WAIT
).
events_waits_history
и
events_waits_history_long
.mutex_instances
показывает, что mutex теперь принадлежит потоку
(в столбце THREAD_ID
).Когда поток отпирает mutex,
mutex_instances
показывает, что у mutex теперь нет никакого владельца
(THREAD_ID
NULL
).
mutex_instances
.
Выполняя запросы на обеих из следующих таблиц, контролирующее приложение или DBA могут обнаружить узкие места или тупики между потоками, которые вовлекают mutex:
events_waits_current
, чтобы видеть, какой mutex ждет поток.
mutex_instances
, чтобы видеть, какому другому потоку в настоящее
время принадлежит mutex.Таблица rwlock_instances
приводит все rwlock
(read write lock) случаи, замеченные Performance Schema в то время, как
сервер выполняется. rwlock
механизм синхронизации, используемый
в коде, чтобы провести в жизнь то, который поток в установленный срок может
иметь доступ к некоторому общему ресурсу по определенным правилам.
Ресурс, как говорят, является защищенным rwlock
.
Доступ совместно использован (у многих потоков может быть блокировка чтения в
то же самое время), исключительный (только у одного потока может быть
блокировка записи в установленный срок) или совместно
используемо-исключительный (у потока может быть блокировка записи, разрешая
непоследовательные чтения другими потоками). Совместно используемый
эксклюзивный доступ иначе известен как sxlock
и был введен в
MySQL 5.7, чтобы оптимизировать параллелизм и улучшить масштабируемость
для чтения-записи.
В зависимости от того, сколько потоков просят блокировку, и природы блокировок, которые требуются, доступ можно или предоставить в совместно используемом режиме, исключительном режиме, совместно используемо-исключительном режиме или не предоставить вообще, ожидая сначала завершения других потоков.
У rwlock_instances
есть эти столбцы:
NAME
Инструментальное имя, связанное с блокировкой.
OBJECT_INSTANCE_BEGIN
Адрес в памяти об инструментованной блокировке.
WRITE_LOCKED_BY_THREAD_ID
Когда поток в настоящее время имеет rwlock
заблокированную в
исключительном (записи) режиме, WRITE_LOCKED_BY_THREAD_ID
THREAD_ID
потока блокировки, иначе NULL
.
READ_LOCKED_BY_COUNT
Когда поток в настоящее время имеет rwlock
заблокированную в
совместно используемом (чтение) режиме, READ_LOCKED_BY_COUNT
увеличен на 1. Это только счетчик, таким образом, это не может использоваться
непосредственно, чтобы найти, какой поток держит блокировку чтения, но это
может использоваться, чтобы видеть, есть ли чтение на rwlock
,
и сколько читателей в настоящее время активно.
У rwlock_instances
есть эти индексы:
Первичный ключ на (OBJECT_INSTANCE_BEGIN
).
NAME
).WRITE_LOCKED_BY_THREAD_ID
).TRUNCATE TABLE
не
позволен для
rwlock_instances
.
Выполняя запросы на обеих из следующих таблиц, контролирующее приложение или DBA могут обнаружить некоторые узкие места или тупики между потоками, которые вовлекают блокировки:
events_waits_current
, чтобы видеть, что
поток ждет rwlock
.
rwlock_instances
, чтобы видеть который другой поток в настоящее
время имеет rwlock
.Есть ограничение:
rwlock_instances
может использоваться только, чтобы
идентифицировать поток, держащий блокировку записи, но не потоки,
держащие блокировку чтения.
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
У сервера есть сокет для каждого сетевого протокола,
который он поддерживает. У инструментов, связанных с сокетами для TCP/IP или
соединений файла сокета Unix, есть socket_type
server_tcpip_socket
или
server_unix_socket
, соответственно.
socket_type
client_connection
.socket_instances
, соответствующая ему удалена.У socket_instances
есть эти столбцы:
EVENT_NAME
Название инструмента wait/io/socket/*
, который произвел
случай. Это значение NAME
из
setup_instruments
. Инструментальные имена могут иметь многое частей и сформировать
иерархию, как обсуждено в
разделе 23.4.
OBJECT_INSTANCE_BEGIN
Этот столбец уникально идентифицирует сокет. Значение адрес объекта в памяти.
THREAD_ID
Внутренний идентификатор потока, назначенный сервером. Каждым сокетом управляет единственный поток, таким образом, каждый сокет может быть отображен на поток, который может быть отображен на процесс сервера.
SOCKET_ID
Внутренний дескриптор, назначенный на сокет.
IP
IP-адрес клиента. Значение может быть адресом IPv4, IPv6 или пустым, чтобы указать на соединение файла сокета Unix.
PORT
Номер порта TCP/IP в диапазоне от 0 до 65535.
STATE
Состояние сокета IDLE
или ACTIVE
.
Ожидания для активных сокетов прослежены, используя соответствующий
инструмент сокета. Ожидания для неактивных сокетов прослежены,
используя инструмент idle
.
Сокет неактивен, если ждет запроса от клиента. Когда сокет становится
неактивным, строка событий в
socket_instances
отслеживает переход сокета от состояния
ACTIVE
в IDLE
. Значение EVENT_NAME
остается wait/io/socket/*
, но синхронизация для инструмента
приостановлена. Вместо этого случай произведен в таблице
events_waits_current
с EVENT_NAME
idle
.
Когда следующий запрос получен, idle
заканчивается,
сокета переходит от IDLE
к ACTIVE
, а
синхронизация инструмента сокета восстанавливается.
У socket_instances
есть эти индексы:
Первичный ключ на (OBJECT_INSTANCE_BEGIN
).
THREAD_ID
).SOCKET_ID
).IP
, PORT
).TRUNCATE TABLE
не
позволен для
socket_instances
.
Значение комбинации столбца IP:PORT
идентифицирует
соединение. Это значение комбинации используется в столбце
the OBJECT_NAME
таблицы events_waits_
, чтобы идентифицировать соединение, из которого
прибывают события сокета:xxx
Для сокета домена Unix
(server_unix_socket
) порт 0, IP ''
.
client_connection
) порт 0, IP ''
.server_tcpip_socket
), порт
всегда основной порт (например, 3306), IP всегда 0.0.0.0
.client_connection
)
порт тот, что сервер назначает, но никогда 0. IP указывает IP удаленного узла
(127.0.0.1
или ::1
для localhost).Эти таблицы хранят ожидание события:
events_waits_current
: Поток ждет события.
events_waits_history
: Новые события ожидания каждого потока.
events_waits_history_long
: Новые события ожидания повсюду.
Следующие разделы описывают те таблицы. Есть также сводные таблицы совокупной информации о событиях ожидания, см. раздел 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';
events_waits_current
содержит текущие события ожидания, одна строка на поток,
показывая текущий статус недавно проверенных событий ожидания потока.
Из таблиц, которые содержат строки событий,
events_waits_current
является самой фундаментальной. Другие таблицы, которые содержат
строки событий, логически получены из текущих событий. Например,
events_waits_history
и
events_waits_history_long
собирают новые события ожидания до
постоянного числа строк.
У
events_waits_current
есть эти столбцы:
THREAD_ID
, EVENT_ID
Поток, связанный со случаем, и число текущих событий потока, когда случай
запускается. THREAD_ID
и EVENT_ID
, взятые вместе,
уникально идентифицируют строку. Ни у каких двух строк нет той же
самой пары значений.
END_EVENT_ID
Этот столбец установлен в NULL
, когда случай запускается, и
обновленный к числу текущих событий потока, когда случай заканчивается.
EVENT_NAME
Название инструмента, который произвел случай. Это NAME
из
setup_instruments
. Инструментальные имена могут иметь много частей и сформировать
иерархию, как обсуждено в
разделе 23.4.
SOURCE
Название исходного файла, содержащего инструментованный код, который произвел случай и номер строки в файле, в которой происходит инструментовка. Это позволяет Вам проверить источник, чтобы определить точно, какой код вовлечен. Например, если блокировка или mutex блокируются, Вы можете проверить контекст, в котором это происходит.
TIMER_START
, TIMER_END
,
TIMER_WAIT
Информация о синхронизации для случая. Модуль для этих значений
пикосекунда. TIMER_START
и TIMER_END
указывают, когда синхронизация событий запустилась и закончилась.
TIMER_WAIT
продолжительность события.
Если случай не закончился, TIMER_END
текущее значение таймера и TIMER_WAIT
уже прошедшее время
(TIMER_END
- TIMER_START
).
Если случай произведен из инструмента, который имеет
TIMED = NO
, информация синхронизации не собрана,
TIMER_START
, TIMER_END
и
TIMER_WAIT
NULL
.
SPINS
Для mutex число спинов. Если значение NULL
,
код не использует спины или они не инструментованы.
OBJECT_SCHEMA
, OBJECT_NAME
,
OBJECT_TYPE
, OBJECT_INSTANCE_BEGIN
Эти столбцы идентифицируют объект как действует. Что это означает, зависит от типа объекта.
Для объекта синхронизации (cond
,
mutex
, rwlock
):
OBJECT_SCHEMA
, OBJECT_NAME
и
OBJECT_TYPE
NULL
.
OBJECT_INSTANCE_BEGIN
адрес объекта синхронизации в памяти.
Для объекта ввода/вывода файла:
OBJECT_SCHEMA
NULL
.
OBJECT_NAME
имя файла.OBJECT_TYPE
FILE
.OBJECT_INSTANCE_BEGIN
адрес в памяти.Для объекта сокета:
OBJECT_NAME
IP:PORT
для сокета.
OBJECT_INSTANCE_BEGIN
адрес в памяти.Для табличного объекта ввода/вывода:
OBJECT_SCHEMA
название схемы,
которая содержит таблицу.
OBJECT_NAME
имя таблицы.OBJECT_TYPE
TABLE
для постоянной базовой таблицы или TEMPORARY TABLE
для временной таблицы.OBJECT_INSTANCE_BEGIN
адрес в памяти.У самого значения OBJECT_INSTANCE_BEGIN
нет никакого значения, за исключением того, что различные значения указывают
на различные объекты. OBJECT_INSTANCE_BEGIN
может использоваться
для того, чтобы отладить. Например, это может использоваться с GROUP
BY OBJECT_INSTANCE_BEGIN
, чтобы видеть, что загрузка 1000 mutex
(которые защищают, скажем, 1000 страниц или блоков данных)
распространена равномерно или поражает только несколько узких мест.
Это может помочь Вам коррелировать с другими источниками информации, если Вы
видите тот же самый адрес объекта в файле системного журнала или
другом инструменте отладки.
INDEX_NAME
Имя индекса. PRIMARY
указывает на первичный индекс таблицы.
NULL
значит, что использовались средства,
которые не индексируют.
NESTING_EVENT_ID
EVENT_ID
значение случая, в пределах которого
вложен этот случай.
NESTING_EVENT_TYPE
Тип вложения событий. Значение TRANSACTION
,
STATEMENT
, STAGE
или WAIT
.
OPERATION
Тип работы lock
, read
или write
.
NUMBER_OF_BYTES
Число байтов, прочитанных или записанных. Для табличного ожидания
ввода/вывода (события для инструмента wait/io/table/sql/handler
) NUMBER_OF_BYTES
указывает на число строк. Если значение
больше 1, это случай пакетной работы ввода/вывода. Следующее обсуждение
описывает различие между сообщением о единственной строке и сообщением, что
это отражает пакетный ввод/вывод.
MySQL выполняет соединения, используя выполнение вложенного цикла.
Задание инструментовки Performance Schema должно предоставить количество
строк и накопленное время выполнения на таблицу в соединении. Примите запрос
соединения следующей формы, которая выполнена, используя табличный порядок
соединения t1
, t2
, t3
:
SELECT ... FROM t1 JOIN t2 ON ... JOIN t3 ON ...
Таблица fanout увеличена или уменьшена в числе строк от
добавления таблицы во время обработки соединения. Если разветвление для
таблицы t3
больше 1, большинство операций получения строки для
этой таблицы. Предположите, что соединение получает 10 строк из
t1
, 20 из t2
на строку из t1
и 30
строк из t3
на строку из t2
.
С сообщением единственной строки общее количество инструментованных операций:
10 + (10 * 20) + (10 * 20 * 30) = 6210
Значительное сокращение числа инструментованных операций достижимо,
соединяя их за просмотр (то есть, за уникальную комбинацию строк из
t1
и t2
). С пакетным сообщением ввода/вывода
Performance Schema производит случай для каждого просмотра самой внутренней
таблицы t3
, а не для каждой строки, и число инструментованных
операций строки уменьшается до:
10 + (10 * 20) + (10 * 20) = 410
Это сокращение на 93% иллюстрирует, как сообщающая о пакете стратегия значительно уменьшает издержки Performance Schema для табличного ввода/вывода, сокращая количество сообщений о требованиях. Расплата: меньшая точность для синхронизации событий. А не время для отдельной работы строки как в сообщении на строку, синхронизация для пакетного ввода/вывода включает время, проведенное для таких операций, как буферизация соединения, объединение и возвращение строк клиенту.
Для пакетного ввода/вывода эти условия должны быть истиной:
Выполнение запроса получает доступ к самой внутренней таблице блока запроса (для однотабличного запроса эта таблица считается самой внутренней).
eq_ref
предотвращает использование сообщения пакета).FLAGS
Сохранено для будущего использования.
У
events_waits_current
есть эти индексы:
Первичный ключ на (THREAD_ID
,
EVENT_ID
).
TRUNCATE TABLE
позволен для
events_waits_current
. Это удаляет строки.
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
. Это удаляет строки.
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
. Это удаляет строки.
Инструменты этапа Performance Schema, которые являются шагами во время
процесса выполнения запроса, такими как парсинг запроса, открытие таблицы
или выполнение filesort
. Этапы соответствуют статусам,
отображенным SHOW PROCESSLIST
или видимым в таблице
INFORMATION_SCHEMA.PROCESSLIST
. Этапы начинаются и заканчиваются,
когда статус оценивает изменение.
Эти таблицы хранят события этапа:
events_stages_current
: Текущие события этапа.
events_stages_history
: Новые события этапа для каждого потока.
events_stages_history_long
: Новые события этапа повсюду.
Чтобы включить сбор событий этапа, включите соответствующие инструменты и потребителей.
setup_instruments
содержит инструменты с именами, которые начинаются с
stage
. Кроме тех инструментов, которые предоставляют информацию
о продвижении запроса, эти инструменты отключены по умолчанию. Например:
mysql> SELECT * FROM setup_instruments WHERE NAME RLIKE 'stage/sql/[a-c]'; +----------------------------------------------------+---------+-------+ | NAME | ENABLED | TIMED | +----------------------------------------------------+---------+-------+ | stage/sql/After create | NO | NO | | stage/sql/allocating local table | NO | NO | | stage/sql/altering table | NO | NO | | stage/sql/committing alter table to storage engine | NO | NO | | stage/sql/Changing master | NO | NO | | stage/sql/Checking master version | NO | NO | | stage/sql/checking permissions | NO | NO | | stage/sql/checking privileges on cached query | NO | NO | | stage/sql/checking query cache for query | NO | NO | | stage/sql/cleaning up | NO | NO | | stage/sql/closing tables | NO | NO | | stage/sql/Connecting to master | NO | NO | | stage/sql/converting HEAP to MyISAM | NO | NO | | stage/sql/Copying to group table | NO | NO | | stage/sql/Copying to tmp table | NO | NO | | stage/sql/copy to tmp table | NO | NO | | stage/sql/Creating sort index | NO | NO | | stage/sql/creating table | NO | NO | | stage/sql/Creating tmp table | NO | NO | +----------------------------------------------------+---------+-------+
Инструменты событий этапа, которые предоставляют информацию о продвижении запроса, включены и рассчитаны по умолчанию:
mysql> SELECT * FROM setup_instruments WHERE ENABLED='YES' AND NAME LIKE "stage/%"; +------------------------------------------------------+---------+-------+ | NAME | ENABLED | TIMED | +------------------------------------------------------+---------+-------+ | stage/sql/copy to tmp table | YES | YES | | stage/innodb/alter table (end) | YES | YES | | stage/innodb/alter table (flush) | YES | YES | | stage/innodb/alter table (insert) | YES | YES | | stage/innodb/alter table (log apply index) | YES | YES | | stage/innodb/alter table (log apply table) | YES | YES | | stage/innodb/alter table (merge sort) | YES | YES | | stage/innodb/alter table (read PK and internal sort) | YES | YES | | stage/innodb/buffer pool load | YES | YES | +------------------------------------------------------+---------+-------+
Чтобы изменить набор событий этапа, измените столбцы
ENABLED
и TIMING
соответствующих инструментов. Например:
mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME = 'stage/sql/altering table';
setup_consumers
содержит потребительские значения с именами, соответствующими текущим и
недавним именам таблиц этапа событий. Эти потребители могут использоваться,
чтобы фильтровать набор событий этапа.
Потребители этапа отключены по умолчанию:
mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%stages%'; +----------------------------+---------+ | NAME | ENABLED | +----------------------------+---------+ | events_stages_current | NO | | events_stages_history | NO | | events_stages_history_long | NO | +----------------------------+---------+
Чтобы включить всех потребителей этапа:
mysql> UPDATE setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%stages%';
setup_timers
содержит строку NAME
со значением stage
, которая
указывает на модуль для синхронизации этапа событий.
Модуль по умолчанию NANOSECOND
.
mysql> SELECT * FROM setup_timers WHERE NAME = 'stage'; +-------+------------+ | NAME | TIMER_NAME | +-------+------------+ | stage | NANOSECOND | +-------+------------+
Чтобы изменить модуль синхронизации, измените
значение TIMER_NAME
:
mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND' WHERE NAME = 'stage';
Таблицы событий этапа Performance Schema содержат два столбца, которые, вместе взятые, обеспечивают индикатор хода выполнения этапа для каждой строки:
WORK_COMPLETED
: Число единиц работы, которые
завершились для этапа.
WORK_ESTIMATED
: Число единиц работы, которые
ожидаются для этапа.Каждый столбец NULL
, если никакая информация о продвижении не
предоставлена для инструмента. Интерпретация информации, если это доступно,
зависит полностью от инструментального выполнения. Таблицы Performance Schema
обеспечивают контейнер, чтобы хранить данные продвижения, но не делают
предположения о семантике метрики непосредственно:
Единица работы является метрикой целого числа, которая увеличивается в течение долгого времени во время выполнения, такое как число байтов, строк, файлов или обработанных таблиц. Определение единицы работы для особого инструмента оставляют коду инструментовки, обеспечивающему данные.
WORK_COMPLETED
может увеличиться на один
или много модулей за один раз, в зависимости от инструментованного кода.WORK_ESTIMATED
может измениться во время этапа, в
зависимости от инструментованного кода.Инструментовка для индикатора хода выполнения этапа событий может осуществить любое из следующих поведений:
Никакого прогресса нет.
Это самый типичный случай, где никакие данные о продвижении не обеспечены.
Столбцы WORK_COMPLETED
и
WORK_ESTIMATED
оба NULL
.
Только столбец WORK_COMPLETED
является значащим. Никакие
данные не предусмотрены для WORK_ESTIMATED
,
который выводит на экран 0.
Запрашивая таблицу
events_stages_current
для проверенного сеанса, контролирующее
приложение может сообщить, сколько работы до сих пор выполнялось, но не может
сообщить, является ли этап близким к завершению. В настоящее время никакие
этапы не инструментованы таким образом.
Столбцы WORK_COMPLETED
и WORK_ESTIMATED
являются оба значащими.
Этот тип индикатора хода выполнения является подходящим для работы с
определенным критерием завершения, таким как инструмент табличной копии,
описанный позже. Запрашивая таблицу
events_stages_current
для проверенного сеанса, контролирующее приложение может
сообщить, сколько работы до сих пор выполнялось, и может сообщить о полном
проценте завершения для этапа, вычисляя коэффициент
WORK_COMPLETED
/WORK_ESTIMATED
.
Инструмент stage/sql/copy to tmp table
иллюстрирует, как
работают индикаторы хода выполнения. Во время выполнения
ALTER TABLE
этап stage/sql/copy to tmp table
используется, и этот этап может
выполняться потенциально в течение долгого времени, в зависимости
от размера данных.
У задачи табличной копии есть определенное завершение
(все строки скопированы) и stage/sql/copy to tmp table
инструментован к предоставленной ограниченной информации о продвижении:
используемая единица работы является числом скопированных строк,
WORK_COMPLETED
и WORK_ESTIMATED
являются значащими,
а их отношение указывает на процент выполнения задачи.
Чтобы включить инструмент и соответствующих потребителей, выполните эти запросы:
mysql> UPDATE setup_instruments SET ENABLED='YES' WHERE NAME='stage/sql/copy to tmp table'; mysql> UPDATE setup_consumers SET ENABLED='YES' WHERE NAME LIKE 'events_stages_%';
Чтобы видеть ход продолжающегося запроса
ALTER TABLE
,
выберите из таблицы
events_stages_current
.
events_stages_current
содержит текущие события этапа, одну строку
на поток, показывая текущий статус нового отслеживаемого
события этапа потока.
Из таблиц, которые содержат строки этапа событий,
events_stages_current
является самой фундаментальной. Другие таблицы, которые содержат
строки этапа событий, логически получены из текущих событий. Например,
events_stages_history
и
events_stages_history_long
собирают новые события этапа до
постоянного числа строк.
У
events_stages_current
есть эти столбцы:
THREAD_ID
, EVENT_ID
Поток, связанный со случаем и числом событий потока,
когда случай запускается. THREAD_ID
и EVENT_ID
,
взятые вместе, уникально идентифицируют строку. Ни у каких двух строк нет той
же самой пары значений.
END_EVENT_ID
Этот столбец установлен в NULL
, когда случай запускается, и
обновлен к числу событий потока, когда случай заканчивается.
EVENT_NAME
Название инструмента, который произвел случай. Это значение
NAME
из
setup_instruments
. Инструментальные имена могут иметь много частей
и сформировать иерархию, как обсуждено в
разделе 23.4.
SOURCE
Название исходного файла, содержащего инструментованный код, который произвел случай и номер строки в файле, в которой происходит инструментовка. Это позволяет Вам проверить источник, чтобы определить точно, какой код вовлечен.
TIMER_START
, TIMER_END
,
TIMER_WAIT
Информация о синхронизации для случая. Модуль для этих значений
пикосекунды. TIMER_START
и TIMER_END
указывают, когда синхронизация событий запустилась и закончилась.
TIMER_WAIT
продолжительность событий.
Если случай не закончился, TIMER_END
текущее значение таймера и TIMER_WAIT
время, законченное до сих
пор (TIMER_END
- TIMER_START
).
Если случай произведен из инструмента, который имеет
TIMED = NO
, информация синхронизации не собрана,
TIMER_START
, TIMER_END
и
TIMER_WAIT
все NULL
.
WORK_COMPLETED
, WORK_ESTIMATED
Эти столбцы предоставляют информацию о продвижении этапа для
инструментов, которые были осуществлены, чтобы произвести такую информацию.
WORK_COMPLETED
указывает, сколько единиц работы было завершено
для этапа, а WORK_ESTIMATED
указывает, сколько единиц работы ожидается для этапа.
NESTING_EVENT_ID
Значение EVENT_ID
случая, в пределах которого вложен этот
случай. Событие вложения для случая этапа обычно событие запроса.
NESTING_EVENT_TYPE
Тип вложения событий. Значение TRANSACTION
,
STATEMENT
, STAGE
или
WAIT
.
У
events_stages_current
есть эти индексы:
Первичный ключ на (THREAD_ID
, EVENT_ID
).
TRUNCATE TABLE
позволен
на
events_stages_current
. Это удаляет строки.
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
. Это удаляет строки.
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
. Это удаляет строки.
Эти таблицы хранят события запросов:
events_statements_current
: Текущие события запросов.
events_statements_history
: Новые события запросов
для каждого потока.
events_statements_history_long
: Новые события запросов повсюду.
prepared_statements_instances
: Готовые запросы и статистика.
Чтобы включить сбор событий запросов, включите соответствующие инструменты и потребителей.
Таблица
setup_instruments
содержит инструменты с именами, которые
начинаются с statement
. Эти инструменты включены по умолчанию:
mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'statement/%'; +--------------------------------+---------+-------+ | NAME | ENABLED | TIMED | +--------------------------------+---------+-------+ | statement/sql/select | YES | YES | | statement/sql/create_table | YES | YES | | statement/sql/create_index | YES | YES | ... | statement/sp/stmt | YES | YES | | statement/sp/set | YES | YES | | statement/sp/set_trigger_field | YES | YES | | statement/scheduler/event | YES | YES | | statement/com/Sleep | YES | YES | | statement/com/Quit | YES | YES | | statement/com/Init DB | YES | YES | ... | statement/abstract/Query | YES | YES | | statement/abstract/new_packet | YES | YES | | statement/abstract/relay_log | YES | YES | +--------------------------------+---------+-------+
Чтобы изменить набор событий запросов, измените столбцы
ENABLED
и TIMING
соответствующих инструментов. Например:
mysql> UPDATE setup_instruments SET ENABLED = 'NO' WHERE NAME LIKE 'statement/com/%';
setup_consumers
содержит потребительские значения с именами, соответствующими текущим и
недавним именам событий запросов и потребителю обзора запросов.
Эти потребители могут использоваться, чтобы фильтровать набор событий.
events_statements_current
,
events_statements_history
и statements_digest
включены по умолчанию:
mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%statements%'; +--------------------------------+---------+ | NAME | ENABLED | +--------------------------------+---------+ | events_statements_current | YES | | events_statements_history | YES | | events_statements_history_long | NO | | statements_digest | YES | +--------------------------------+---------+
Чтобы включить всех потребителей, сделайте это:
mysql> UPDATE setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%statements%';
setup_timers
содержит строку со значением NAME
statement
,
которая указывает на модуль для синхронизации запросы событий.
Модуль по умолчанию NANOSECOND
.
mysql> SELECT * FROM setup_timers WHERE NAME = 'statement'; +-----------+------------+ | NAME | TIMER_NAME | +-----------+------------+ | statement | NANOSECOND | +-----------+------------+
Чтобы изменить модуль синхронизации,
измените значение TIMER_NAME
:
mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND' WHERE NAME = 'statement';
Контроль запросов начинается с момента, когда сервер видит, что на потоке требуется активность, до момента, когда вся деятельность прекратилась. Как правило, это означает по времени от момента, когда сервер получает первый пакет от клиента, до времени, когда сервер закончил посылать ответ. Запросы в пределах сохраненных программ проверены как другие запросы.
Когда Performance Schema инструментует запрос (команду сервера или запрос SQL), это использует инструментальные имена, которые проистекают из более общего (или абстрактного) к более определенному, пока это не достигает заключительного инструментального имени.
Заключительные инструментальные имена соответствуют командам сервера и запросам SQL:
Команды сервера соответствуют кодам
COM_
, определенным в заголовочном файле
xxx
mysql_com.h
и обработанным в sql/sql_parse.cc
.
Примеры: COM_PING
и COM_QUIT
.
У инструментов для команд есть имена, которые начинаются на
statement/com
, к примеру, statement/com/Ping
и
statement/com/Quit
.
DELETE FROM t1
или SELECT * FROM t2
.
У инструментов для запросов SQL есть имена, которые начинаются с
statement/sql
, например, statement/sql/delete
и
statement/sql/select
.Некоторые заключительные инструментальные имена являются определенными для обработки ошибок:
statement/com/Error
считает
сообщения, полученные сервером, которые являются вне группы. Это может
использоваться, чтобы обнаружить команды, посланные клиентами, которых не
понимает сервер. Это может быть полезно в таких целях, как идентификация
клиентов, которые являются неправильно настроенными или используют версии
MySQL, более свежие, чем сервер, или клиенты, которые пытаются
напасть на сервер.
statement/sql/error
считает запросы SQL, которые сервер не
в состоянии разобрать. Это может использоваться, чтобы обнаружить уродливые
запросы, посланные клиентами. Запрос, который сервер не в состоянии
разобрать, отличается от запроса, который разбирает, но терпит неудачу из-за
ошибки во время выполнения. Например, SELECT * FROM
неправилен, и используется инструмент statement/sql/error
.
В отличие от этого, SELECT *
разобран, но терпит неудачу с
ошибкой No tables used
. В этом случае используется
statement/sql/select
и случай запроса содержит информацию, чтобы
указать на природу ошибки.Запрос может быть получен из любого из этих источников:
Как команда или запрос от клиента, который посылает запрос как пакет.
Детали для запроса первоначально неизвестны и Performance Schema раблтает от абстрактных до определенных инструментальных имен в последовательности, которая зависит от источника запроса.
Для запроса, полученного от клиента:
Когда сервер обнаруживает новый пакет на уровне сокета,
новое запрос запущен с абстрактного инструментального названия
statement/abstract/new_packet
.
COM_PING
, инструментальное имя становится
statement/com/Ping
и это заключительное имя. Если запрос пакет
COM_QUERY
, это, как известно, соответствует запросу SQL, но не
особому типу запроса. В этом случае инструмент изменяется от одного
абстрактного имени к более определенному, но все еще абстрактногому имени,
statement/abstract/Query
и запрос
требует дальнейшей классификации.INSERT
, Performance Schema
совершенствует инструментальное имя от statement/abstract/Query
к statement/sql/insert
, что является заключительным именем.
Для чтения запроса как запроса от протокола ведомого устройства:
Запросы в журнале сохранены как текст и считаны как есть.
Нет никакого сетевого протокола, таким образом, инструмент
statement/abstract/new_packet
не используется. Вместо этого
начальный инструмент statement/abstract/relay_log
.
INSERT
, Performance
Schema совершенствует инструментальное имя от
statement/abstract/Query
до
statement/sql/insert
, что является заключительным именем.
Предыдущее описание применяется только для основанной на запросе репликации. Для основанной на строке табличный ввод/вывод, сделанный на ведомом устройстве, когда это обрабатывает изменения строки, может быть инструментован, но события строки в журнале не появляются как дискретные запросы.
Для запроса, полученного от 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
,
потому что никакой запрос никогда не классифицируется с абстрактным
инструментом как заключительным именем запроса.
events_statements_current
содержит текущие события запроса, одну
строку на поток, показывая текущий статус новых отслеживаемых за развитием
события запросов потока.
Из таблиц, которые содержат строки запросов событий,
events_statements_current
является самой фундаментальной. Другие
таблицы, которые содержат строки запросы событий, логически получены из
текущих событий. Например,
events_statements_history
и
events_statements_history_long
собирают
новые события запроса до постоянного числа строк.
У
events_statements_current
есть эти столбцы:
THREAD_ID
, EVENT_ID
.
Поток, связанный со случаем и текущим числом событий потока,
когда случай запускается. THREAD_ID
и EVENT_ID
вместе уникально идентифицируют строку. Ни у каких двух строк нет той же
самой пары значений.
END_EVENT_ID
Этот столбец установлен в NULL
, когда случай запускается
и обновлен к числу событий потока, когда случай заканчивается.
EVENT_NAME
Название инструмента, у которого был собран случай. Это NAME
из таблицы
setup_instruments
. Инструментальные имена могут иметь много частей
и сформировать иерархию, как обсуждено в
разделе 23.4.
Для запросов SQL EVENT_NAME
первоначально
statement/com/Query
пока запрос не разобран, затем изменяется на
более соответствующее значение, как описано в
разделе 23.9.6.
SOURCE
Название исходного файла, содержащего инструментованный код, который произвел случай и номер строки в файле, в котором происходит инструментовка. Это позволяет Вам проверить источник, чтобы определить точно, какой код вовлечен.
TIMER_START
, TIMER_END
,
TIMER_WAIT
Информация о синхронизации для случая. Модуль для этих значений
пикосекунды TIMER_START
и TIMER_END
указывают, когда синхронизация событий запустилась и закончилась.
TIMER_WAIT
продолжительность событий.
Если случай не закончился, TIMER_END
текущее значение таймера и TIMER_WAIT
время, законченное до сих пор
(TIMER_END
- TIMER_START
).
Если случай произведен из инструмента, который имеет
TIMED = NO
, информация синхронизации не собрана, а
TIMER_START
, TIMER_END
и
TIMER_WAIT
NULL
.
LOCK_TIME
Время, потраченное на ожидание табличных блокировок. Это значение вычислено в микросекундах, но нормализовано к пикосекундам для более легкого сравнения с другими таймерами Performance Schema.
SQL_TEXT
Текст запроса SQL. Для команды, не связанной с запросом
SQL, значение NULL
.
Максимальное количество байтов, чтобы вывести на экран может быть
изменено, изменяя при запуске сервера переменную
performance_schema_max_sql_text_length
.
DIGEST
Обзор запроса MD5 как строка из 32 шестнадцатеричных символов или
NULL
, если потребитель
statement_digest
no
.
DIGEST_TEXT
Нормализованный текст обзора запроса или NULL
, если
потребитель statement_digest
no
.
Перменная
performance_schema_max_digest_length
определяет максимальное количество байтов, доступных для вычислительных
обзоров запроса. Однако, длина отображения обзоров запроса может быть более
длительной, чем доступный размер буфера из-за кодирования компонентов
запроса, таких как ключевые слова и буквальные значения в буфере обзора.
Следовательно, значения, выбранные из столбца DIGEST_TEXT
таблиц событий запроса, может казаться, превышает
performance_schema_max_digest_length
.
CURRENT_SCHEMA
База данных значения по умолчанию для запроса,
NULL
, если нет.
OBJECT_SCHEMA
, OBJECT_NAME
,
OBJECT_TYPE
Для вложенных запросов (сохраненные программы), эти столбцы содержат
информацию о родительском запросе. Иначе NULL
.
OBJECT_INSTANCE_BEGIN
Этот столбец идентифицирует запрос. Значение адрес объекта в памяти.
MYSQL_ERRNO
Код ошибки из области диагностики.
RETURNED_SQLSTATE
Значение SQLSTATE из области диагностики.
MESSAGE_TEXT
Сообщение об ошибке запроса из области диагностики.
ERRORS
Произошла ли ошибка для запроса. Значение 0, если значение SQLSTATE
начинается с 00
(выполнен) или 01
(предупреждение).
Значение 1, если SQLSTATE иное.
WARNINGS
Число предупреждений из области диагностики.
ROWS_AFFECTED
Число строк, затронутых запросом. Для описания значения "затронутых" см. раздел 25.8.7.1.
ROWS_SENT
Число строк, возвращенных запросом.
ROWS_EXAMINED
Число строк, прочитанных из механизмов хранения во время выполнения запроса.
CREATED_TMP_DISK_TABLES
Как переменная состояния
Created_tmp_disk_tables
, но для запроса.
CREATED_TMP_TABLES
Как переменная состояния
Created_tmp_tables
, но для запроса.
SELECT_FULL_JOIN
Как переменная состояния
Select_full_join
, но для запроса.
SELECT_FULL_RANGE_JOIN
Как переменная состояния
Select_full_range_join
, но для запроса.
SELECT_RANGE
Как переменная состояния
Select_range
,
но для запроса.
SELECT_RANGE_CHECK
Как переменная состояния
Select_range_check
, но для запроса.
SELECT_SCAN
Как переменная состояния
Select_scan
,
но для запроса.
SORT_MERGE_PASSES
Как переменная состояния
Sort_merge_passes
, но для запроса.
SORT_RANGE
Как переменная состояния
a href="server.htm#statvar_Sort_range">Sort_range
,
но для запроса.
SORT_ROWS
Как переменная состояния
Sort_rows
,
но для запроса.
SORT_SCAN
Как переменная состояния
Sort_scan
,
но для запроса.
NO_INDEX_USED
1, если запрос выполнил сканирование таблицы, не используя индексирование, 0 иначе.
NO_GOOD_INDEX_USED
1, если сервер не нашел индекс, чтобы использовать для запроса, 0 иначе.
Для дополнительной информации см. описание столбца Extra
из
вывода EXPLAIN
для значения
Range checked for each record
разделе 9.8.2.
NESTING_EVENT_ID
, NESTING_EVENT_TYPE
,
NESTING_EVENT_LEVEL
Эти три столбца используются с другими столбцами, чтобы предоставить информацию следующим образом для запросов верхнего уровня (невложенных) и вложенные запросы (выполненных в пределах сохраненной программы).
Для высокоуровневых запросов:
OBJECT_TYPE = NULL OBJECT_SCHEMA = NULL OBJECT_NAME = NULL NESTING_EVENT_ID = NULL NESTING_EVENT_TYPE = NULL NESTING_LEVEL = 0
Для вложенных запросов:
OBJECT_TYPE = родительский тип объекта запроса OBJECT_SCHEMA = родительская схема объекта OBJECT_NAME = родительское название объекта NESTING_EVENT_ID = EVENT_ID родительского запроса NESTING_EVENT_TYPE = 'STATEMENT' NESTING_LEVEL = NESTING_LEVEL родительского запроса+1
У
events_statements_current
есть эти индексы:
Первичный ключ на (THREAD_ID
, EVENT_ID
).
TRUNCATE TABLE
позволен
на
events_statements_current
. Это удаляет строки.
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
. Это удаляет строки.
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
. Это удаляет строки.
Performance Schema обеспечивает инструментовку для готовых запросов, для которых есть два протокола:
Протокол двоичной синхронной передачи данных. К этому получают доступ через MySQL C API, и он отображается на основные команды сервера как показано в следующей таблице.
Функция C API | Соответствующая команда сервера |
---|---|
mysql_stmt_prepare() |
COM_STMT_PREPARE |
mysql_stmt_execute() |
COM_STMT_EXECUTE |
mysql_stmt_close() | COM_STMT_CLOSE
|
Текстовый протокол. К этому получают доступ, используя запросы SQL и отображая на основные команды сервера, как показано в следующей таблице.
SQL-запрос | Соответствующая команда сервера |
---|---|
PREPARE
| SQLCOM_PREPARE |
EXECUTE |
SQLCOM_EXECUTE |
DEALLOCATE
PREPARE , DROP PREPARE
|
SQLCOM_DEALLOCATE PREPARE |
Performance Schema подготовила покрытие инструментовки обоих протоколов. Следующее обсуждение отсылает к командам сервера, а не функциям C API или запросам SQL.
Информация о готовых запросах доступна в таблице
prepared_statements_instances
. Эта таблица включает просмотр
готовых запросов, используемых в сервере, и обеспечивает соединенную
статистику о них. Чтобы управлять размером этой таблицы, установите
при запуске сервера системную переменную
performance_schema_max_prepared_statements_instances
.
Сбор готовой информации о запросе зависит от инструментов запроса,
показанных в следующей таблице. Эти инструменты включены по умолчанию. Чтобы
изменить их, обновите
setup_instruments
.
Инструмент | Команда сервера |
---|---|
statement/com/Prepare |
COM_STMT_PREPARE |
statement/com/Execute |
COM_STMT_EXECUTE |
statement/sql/prepare_sql |
SQLCOM_PREPARE |
statement/sql/execute_sql |
SQLCOM_EXECUTE |
Performance Schema управляет содержанием
prepared_statements_instances
следующим образом:
Подготовка запроса.
Команда COM_STMT_PREPARE
или SQLCOM_PREPARE
создает готовый запрос в сервере. Если запрос успешно инструментован, новая
строка добавлена к
prepared_statements_instances
.
Если запрос не может быть инструментован, увеличена переменная
Performance_schema_prepared_statements_lost
.
Выполнение команды COM_STMT_EXECUTE
или
SQLCOM_PREPARE
для инструментованного готового случая запроса
обновляет соответствующую строку таблицы
prepared_statements_instances
.
Выполнение команды COM_STMT_CLOSE
или
SQLCOM_DEALLOCATE_PREPARE
для инструментованного готового случая
запроса удаляет соответствующую строку таблицы
prepared_statements_instances
. Чтобы избежать утечек ресурса,
удаление происходит, даже если инструменты готового запроса,
описанные ранее, отключены.
У
prepared_statements_instances
есть эти столбцы:
OBJECT_INSTANCE_BEGIN
Адрес в памяти инструментованного готового запроса.
STATEMENT_ID
Внутренний ID, назначенный сервером.
STATEMENT_NAME
Для протокола двоичной синхронной передачи данных этот столбец
NULL
. Для текстового протокола этот столбец внешнее имя,
назначенное пользователем. Например, для следующего запроса SQL, название
готового запроса stmt
:
PREPARE stmt FROM 'SELECT 1';
SQL_TEXT
Готовый текст запроса с маркерами заполнителями ?
.
OWNER_THREAD_ID
, OWNER_EVENT_ID
Эти столбцы указывают на событие, которое создало готовый запрос.
OWNER_OBJECT_TYPE
, OWNER_OBJECT_SCHEMA
,
OWNER_OBJECT_NAME
Для готового запроса, создаваемого сеансом клиента, эти столбцы
NULL
. Для готового запроса, создаваемого сохраненной программой,
эти столбцы указывают на сохраненную программу. Типичная пользовательская
ошибка в том, что пользователь забывает освобождать подготовленные запросы.
Эти столбцы могут использоваться, чтобы найти сохраненные программы, которые
пропускают готовые запросы:
SELECT OWNER_OBJECT_TYPE, OWNER_OBJECT_SCHEMA, OWNER_OBJECT_NAME, STATEMENT_NAME, SQL_TEXT FROM performance_schema.prepared_statements_instances WHERE OWNER_OBJECT_TYPE IS NOT NULL;
TIMER_PREPARE
Время на выполнение подготовки запроса.
COUNT_REPREPARE
Сколько раз запрос был повторно подготовлено внутренне (см. раздел 9.10.4). Статистические данные синхронизации для переподготовки недоступны, потому что это посчитано как часть выполнения запроса, не как отдельная работа.
COUNT_EXECUTE
, SUM_TIMER_EXECUTE
,
MIN_TIMER_EXECUTE
, AVG_TIMER_EXECUTE
,
MAX_TIMER_EXECUTE
Соединенная статистика для выполнения готового запроса.
SUM_xxx
Остающееся столбцы SUM_
то же самое, что касается сводных таблиц запросов (см.
раздел 23.9.15.3).
xxx
У
prepared_statements_instances
есть эти индексы:
Первичный ключ на (OBJECT_INSTANCE_BEGIN
).
STATEMENT_ID
).STATEMENT_NAME
).OWNER_THREAD_ID
, OWNER_EVENT_ID
).
OWNER_OBJECT_TYPE
,
OWNER_OBJECT_SCHEMA
, OWNER_OBJECT_NAME
).
TRUNCATE TABLE
сбрасывает столбцы статистики
prepared_statements_instances
.
Эти таблицы хранят операционные события:
events_transactions_current
: Текущие операционные события.
events_transactions_history
:
Новые операционные события для каждого потока.
events_transactions_history_long
:
Новые операционные события повсюду.Чтобы включить сбор операционных событий, включите соответствующие инструменты и потребителей.
setup_instruments
содержит инструмент transaction
.
Этот инструмент отключен по умолчанию:
mysql> SELECT * FROM setup_instruments WHERE NAME = 'transaction'; +-------------+---------+-------+ | NAME | ENABLED | TIMED | +-------------+---------+-------+ | transaction | NO | NO | +-------------+---------+-------+
Чтобы включить сбор операционных событий, включая информацию о синхронизации:
mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME = 'transaction';
setup_consumers
содержит потребительские значения с именами, соответствующими текущим и
недавним операционным именам таблиц событий. Эти потребители могут
использоваться, чтобы фильтровать набор операционных событий:
mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%transactions%'; +----------------------------------+---------+ | NAME | ENABLED | +----------------------------------+---------+ | events_transactions_current | NO | | events_transactions_history | NO | | events_transactions_history_long | NO | +----------------------------------+---------+
Чтобы включить всех операционных потребителей:
mysql> UPDATE setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%transactions%';
Чтобы включить сбор операционных событий только для определенных операционных таблиц событий, включите соответствующих операционных потребителей.
setup_timers
содержит строку с NAME
transaction
, которая
указывает на модуль для операционной синхронизации событий.
Модуль по умолчанию NANOSECOND
.
mysql> SELECT * FROM setup_timers WHERE NAME = 'transaction'; +-------------+------------+ | NAME | TIMER_NAME | +-------------+------------+ | transaction | NANOSECOND | +-------------+------------+
Чтобы изменить модуль синхронизации, измените TIMER_NAME
:
mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND' WHERE NAME = 'transaction';
В MySQL Server транзакции запускаются явно с этих запросов:
START TRANSACTION | BEGIN | XA START | XA BEGIN
Транзакции также запускаются неявно. Например, когда включена переменная
autocommit
,
запуск каждого запроса запускает новую транзакцию.
Если autocommit
выключена, первый запрос после переданной транзакции отмечает запуск новой
транзакции. Последующие запросы это часть транзакции, пока это не передано.
Транзакции явно заканчиваются этими запросами:
COMMIT | ROLLBACK | XA COMMIT | XA ROLLBACK
Транзакции также заканчиваются неявно, выполнением запросов DDL, запросами блокировки и запросами администрирования сервера.
В следующем обсуждении ссылки на
START TRANSACTION
также применимы к
BEGIN
,
XA START
и
XA BEGIN
. Точно так же
ссылки на COMMIT
и
ROLLBACK
относятся к
XA COMMIT
и
XA ROLLBACK
.
Performance Schema определяет операционные границы аналогично серверу. Запуск и конец операционного случая близко соответствуют соответствующим изменениям состояния в сервере:
Для явно запущенной транзакции операционный случай запускается во
время обработки START TRANSACTION
.
COMMIT
или
ROLLBACK
.Есть тонкие значения к этому подходу:
Операционные события в Performance Schema не полностью включают
события запроса, связанные с передачей
START TRANSACTION
,
COMMIT
или
ROLLBACK
.
Есть тривиальное количество перекрытия синхронизации между операционным
случаем и этими запросыми.
START TRANSACTION
.Чтобы иллюстрировать, рассмотрите следующий сценарий:
1. SET autocommit = OFF; 2. CREATE TABLE t1 (a INT) ENGINE = InnoDB; 3. START TRANSACTION; -- Transaction 1 START 4. INSERT INTO t1 VALUES (1), (2), (3); 5. CREATE TABLE t2 (a INT) ENGINE = MyISAM; -- Transaction 1 COMMIT -- (implicit; DDL forces commit) 6. INSERT INTO t2 VALUES (1), (2), (3); -- Update nontransactional table 7. UPDATE t2 SET a = a + 1; -- ... and again 8. INSERT INTO t1 VALUES (4), (5), (6); -- Write to transactional table -- Transaction 2 START (implicit) 9. COMMIT;-- Transaction 2 COMMIT
С точки зрения сервера, транзакция 1 завершилась, когда таблица
t2
создается. Транзакция 2 не запускается, пока к транзакционный
таблице не получают доступ, несмотря на прошедшие
обновления нетранзакционных таблиц.
С точки зрения Performance Schema, транзакция 2 запускается, когда сервер переходит в активное состояние транзакции. Запросы 6 и 7 не включены в пределы границ транзакции 2, которые совместимы с тем, как сервер пишет транзакции в двоичный журнал.
Три признака определяют транзакции:
Режим доступа (только для чтения, чтение-запись).
SERIALIZABLE
,
REPEATABLE READ
, и т.д.).autocommit
) или явная (выключен
autocommit
).Чтобы уменьшить сложность операционной инструментовки и гарантировать, что собранные операционные данные обеспечивают полные, значащие результаты, все транзакции инструментованы независимо от режима доступа, уровня изоляции или режима autocommit.
Чтобы выборочно исследовать операционную историю, используйте столбцы
признака в операционных таблицах событий: ACCESS_MODE
,
ISOLATION_LEVEL
и AUTOCOMMIT
.
Стоимость операционной инструментовки может быть уменьшена различными путями, такими как включение или отключение операционной инструментовки, согласно пользователю, учетной записи, узлу или потоку (соединению клиента).
Родитель операционного случая это случай, который начал транзакцию.
Для явно запущенной транзакции это включает
START TRANSACTION
и
COMMIT AND CHAIN
. Для неявно
запущенной транзакции это первый запрос, который использует транзакционный
механизм после того, как предыдущая транзакция заканчивается.
Вообще, транзакция высокоуровневый родитель ко всем событиям, начатым во
время транзакции, включая запросы, которые явно заканчивают транзакцию, такие
как COMMIT
и
ROLLBACK
. Исключения: запросы,
которые неявно заканчивают транзакцию, такие как запросы DDL, когда текущая
транзакция должна быть закрыта прежде, чем новый запрос выполнен.
Транзакции и сохраненные события программы связаны следующим образом:
Хранимые процедуры.
Хранимые процедуры работают независимо от транзакций. Хранимая процедура может быть запущена в пределах транзакции, и транзакция может быть запущена или закончена изнутри хранимой процедуры. Если вызвана изнутри транзакции, хранимая процедура может выполнить запросы, которые вызывают передачу родительской транзакции и затем запускают новую транзакцию.
Если хранимая процедура запущена в пределах транзакции, та транзакция родитель случая хранимой процедуры.
Если транзакция запущена хранимой процедурой, хранимая процедура родитель операционного случая.
Сохраненные функции ограничены от порождения явной или неявной передачи или отмены транзакции. Сохраненные функциональные события могут находиться в пределах родительского операционного случая.
Триггеры активируются как часть запроса, обращающегося к таблице, с которой он связан, таким образом, родитель случая триггера всегда запрос, который активирует его.
Триггеры не могут сделать запросы, которые вызывают явную или неявную передают или отмену транзакции.
Выполнение запросов в теле запланированного события имеет место в новом соединении. Вложение запланированного события в пределы родительской транзакции неприменимо.
Запросы Savepoint зарегистрированы как отдельные события.
Операционные события включают отдельные счетчики для
SAVEPOINT
,
ROLLBACK TO SAVEPOINT
и
RELEASE SAVEPOINT
, которые
произошли во время транзакции.
Ошибки и предупреждения, которые происходят в пределах транзакции, зарегистрированы в событиях запросов, но не в соответствующем операционном событии. Это включает определенные для транзакции ошибки и предупреждения, такие как отмена транзакции на нетранзакционный таблице или ошибка последовательности GTID.
events_transactions_current
содержит текущие операционные события,
одну строку на поток, показывая текущий статус нового
отслеживающего потока. Например:
mysql> SELECT * FROM events_transactions_current LIMIT 1\G *************************** 1. row *************************** THREAD_ID: 26 EVENT_ID: 7 END_EVENT_ID: NULL EVENT_NAME: transaction STATE: ACTIVE TRX_ID: NULL GTID: 3E11FA47-71CA-11E1-9E33-C80AA9429562:56 XID: NULL XA_STATE: NULL SOURCE: transaction.cc:150 TIMER_START: 420833537900000 TIMER_END: NULL TIMER_WAIT: NULL ACCESS_MODE: READ WRITE ISOLATION_LEVEL: REPEATABLE READ AUTOCOMMIT: NO NUMBER_OF_SAVEPOINTS: 0 NUMBER_OF_ROLLBACK_TO_SAVEPOINT: 0 NUMBER_OF_RELEASE_SAVEPOINT: 0 OBJECT_INSTANCE_BEGIN: NULL NESTING_EVENT_ID: 6 NESTING_EVENT_TYPE: STATEMENT
Из таблиц, которые содержат операционные строки событий,
events_transactions_current
является самой фундаментальной. Другие
таблицы, которые содержат операционные строки событий, логически получены из
текущих событий. Например,
events_transactions_history
и
events_transactions_history_long
собирают новые операционные события до постоянного числа строк.
У
events_transactions_current
есть эти столбцы:
THREAD_ID
, EVENT_ID
Поток, связанный со случаем и текущим числом событий потока, когда случай
запускается. THREAD_ID
и EVENT_ID
вместе
уникально идентифицируют строку. Ни у каких двух строк нет той же
самой пары значений.
END_EVENT_ID
Этот столбец установлен в NULL
, когда случай запускается и
обновлен к текущему числу событий потока, когда случай заканчивается.
EVENT_NAME
Название инструмента, у которого был собран случай. Это NAME
из setup_instruments
. Инструментальные имена могут иметь много частей и сформировать
иерархию, как обсуждено в
разделе 23.4.
STATE
Текущее операционное состояние. Значение ACTIVE
(после
START TRANSACTION
или
BEGIN
), COMMITTED
(после COMMIT
) или ROLLED
BACK
(после ROLLBACK
).
TRX_ID
Не использован.
GTID
Столбец GTID содержит значение
gtid_next
,
которое может быть одним из ANONYMOUS
, AUTOMATIC
или GTID с использованием формата UUID:NUMBER
.
Для транзакций с использованием
gtid_next=AUTOMATIC
(это все нормальные транзакции клиента),
столбец GTID меняется, когда транзакция завершается и фактический GTID
назначен. Если gtid_mode
ON
или ON_PERMISSIVE
, столбец GTID
изменяется на GTID транзакции. Если gtid_mode
OFF
или OFF_PERMISSIVE
, столбец GTID
изменяется на ANONYMOUS
.
XID_FORMAT_ID
, XID_GTRID
,
XID_BQUAL
Компоненты операционного идентификатора XA. Их формат описан в разделе 14.3.7.1.
XA_STATE
Состояние транзакции XA. Значение ACTIVE
(после
XA START
), IDLE
(после XA END
),
PREPARED
(после XA
PREPARE
), ROLLED BACK
(после
XA ROLLBACK
) или
COMMITTED
(после XA
COMMIT
).
SOURCE
Название исходного файла, содержащего инструментованный код, который произвел случай и номер строки в файле, в котором происходит инструментовка. Это позволяет Вам проверить источник, чтобы определить точно, какой код вовлечен.
TIMER_START
, TIMER_END
,
TIMER_WAIT
Информация о синхронизации для случая. Модуль для этих значений
пикосекунды. TIMER_START
и TIMER_END
указывают, когда синхронизация событий запустилась и закончилась.
TIMER_WAIT
продолжительность.
Если случай не закончился, TIMER_END
текущее значение
таймера и TIMER_WAIT
время, законченное до сих пор
(TIMER_END
- TIMER_START
).
Если случай произведен из инструмента, который имеет
TIMED = NO
, информация синхронизации не собрана, и
TIMER_START
, TIMER_END
и
TIMER_WAIT
NULL
.
ACCESS_MODE
Операционный режим доступа. Значение READ ONLY
или READ WRITE
.
ISOLATION_LEVEL
Операционный уровень изоляции. Значение
REPEATABLE READ
, READ COMMITTED
, READ
UNCOMMITTED
или
SERIALIZABLE
.
AUTOCOMMIT
Был ли режим autcommit включен, когда транзакция запускалась.
NUMBER_OF_SAVEPOINTS
,
NUMBER_OF_ROLLBACK_TO_SAVEPOINT
,
NUMBER_OF_RELEASE_SAVEPOINT
Число запросов SAVEPOINT
,
ROLLBACK TO SAVEPOINT
и
RELEASE SAVEPOINT
во время транзакции.
OBJECT_INSTANCE_BEGIN
Не использован.
NESTING_EVENT_ID
EVENT_ID
случая, в пределах которого вложен этот случай.
NESTING_EVENT_TYPE
Тип вложения событий. Значение
TRANSACTION
, STATEMENT
, STAGE
или
WAIT
. TRANSACTION
не будет появляться, потому что
транзакции не могут быть вложены.
У
events_transactions_current
есть эти индексы:
Первичный ключ на (THREAD_ID
,
EVENT_ID
).
TRUNCATE TABLE
позволен
на
events_transactions_current
. Это удаляет строки.
Таблица
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
. Это удаляет строки.
Таблица
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
. Это удаляет строки.
Когда клиент соединяется с сервером MySQL, он делает это под именем пользователя и от конкретного узла. Performance Schema обеспечивает статистику об этих соединениях, отслеживая их для учетной записи (комбинация пользователя и узла), а также отдельно для имени пользователя и имени хоста, используя эти таблицы:
accounts
:
Статистика соединения по учетной записи клиента.
hosts
:
Статистика соединения по имени хоста клиента.users
:
Статистика соединения по имени пользователя клиента.Значение account в таблицах соединения подобно его значению в
таблицах привилегий MySQL базы данных mysql
,
в том смысле, что термин относится к комбинации значений узла и пользователя.
Они отличаются в том, что для таблиц привилегий часть узла учетной записи
может быть образцом, тогда как для Performance Schema значение узла всегда
определенное имя хоста.
Каждая таблица соединения имеет столбцы CURRENT_CONNECTIONS
и
TOTAL_CONNECTIONS
, чтобы отследить текущее и общее количество
соединений за преиод слежения на котором базируются
статистические данные. Таблицы отличаются по тому, что они используют для
значения отслеживания. Таблица
accounts
имеет столбцы
USER
и HOST
, чтобы отследить соединения на
комбинацию пользователя и узла. users
и hosts
имеют
столбцы USER
и HOST
, соответственно, чтобы
отследить соединения за имя пользователя и имя хоста.
Performance Schema также считает внутренние потоки и потоки для
пользовательских сеансов, которые были не в состоянии подтвердить
подлинность, используя строки со столбцами
USER
и HOST
NULL
.
Предположите, что клиенты user1
и user2
соединились с машин hosta
и hostb
. Performance
Schema отслеживает соединения следующим образом:
Таблица accounts
имеет четыре строки, считая одно соединение за учетную запись, для
user1
/hosta
, user1
/hostb
,
user2
/hosta
и
user2
/hostb
.
hosts
имеет
имеет две строки для hosta
и hostb
,
считая два соединения на имя хоста.users
имеет две строки для user1
и user2
,
считая два соединения на имя пользователя.Когда клиент соединяется, Performance Schema определяет, какая строка в
каждой таблице соединения применяется, используя значение отслеживания,
соответствующее каждой таблице. Если нет такой строки, она добавлена. Тогда
Performance Schema постепенно увеличивает столбцы CURRENT_CONNECTIONS
и TOTAL_CONNECTIONS
в этой строке.
Когда клиент разъединяется, Performance Schema уменьшает столбец
CURRENT_CONNECTIONS
в строке и не меняет
столбец TOTAL_CONNECTIONS
.
TRUNCATE TABLE
позволен
на таблицах соединения. Это имеет эффекты:
Строки удалены для учетных записей, узлов или пользователей, у
которых нет никаких текущих соединений (строки с
CURRENT_CONNECTIONS = 0
).
CURRENT_CONNECTIONS > 0
,
TOTAL_CONNECTIONS
сброшен к CURRENT_CONNECTIONS
.
Performance Schema поддерживает сводные таблицы, которые ведут совокупную
статистику соединений для различных типов случаев по учетной записи, узлу или
пользователю. Эти таблицы имеют в имени _summary_by_account
,
_summary_by_host
или _summary_by_user
.
Чтобы идентифицировать их, используйте этот запрос:
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'performance_schema' AND TABLE_NAME REGEXP '_summary_by_(account|host|user)' ORDER BY TABLE_NAME; +------------------------------------------------------+ | TABLE_NAME | +------------------------------------------------------+ | events_errors_summary_by_account_by_error| | events_errors_summary_by_host_by_error | | events_errors_summary_by_user_by_error | | events_stages_summary_by_account_by_event_name | | events_stages_summary_by_host_by_event_name| | events_stages_summary_by_user_by_event_name| | events_statements_summary_by_account_by_event_name | | events_statements_summary_by_host_by_event_name| | events_statements_summary_by_user_by_event_name| | events_transactions_summary_by_account_by_event_name | | events_transactions_summary_by_host_by_event_name| | events_transactions_summary_by_user_by_event_name| | events_waits_summary_by_account_by_event_name | | events_waits_summary_by_host_by_event_name | | events_waits_summary_by_user_by_event_name | | memory_summary_by_account_by_event_name | | memory_summary_by_host_by_event_name | | memory_summary_by_user_by_event_name | +------------------------------------------------------+
Для деталей об отдельных сводных таблицах соединения, консультируйтесь с разделом, который описывает таблицы для полученного в итоге типа событий:
Резюме событий ожидания: раздел 23.9.15.1.
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
неявно усекает сводные таблицы событий ожидания, которые соединены с учетной
записью, узлом, пользователем или потоком.
Таблица accounts
содержит строку для каждой учетной записи, которая соединилась с сервером
MySQL. Для каждой учетной записи таблица считает текущее и общее количество
соединений. Табличный размер задан при запуске сервера.
Чтобы установить табличный размер явно, установите системную переменную
performance_schema_accounts_size
при запуске сервера.
Чтобы отключить статистику учетной записи, установите эту переменную в 0.
Таблица accounts
имеет следующие столбцы. Для описания того, как Performance Schema
поддерживает строки в этой таблице, включая эффект
TRUNCATE TABLE
, см.
раздел 23.9.8.
USER
Имя пользователя клиента для соединения. Это NULL
для внутреннего потока или для пользовательского сеанса, который был не в
состоянии подтвердить подлинность.
HOST
Узел, с которого соединялся клиент. Это NULL
для внутреннего потока или для пользовательского сеанса, который был не в
состоянии подтвердить подлинность.
CURRENT_CONNECTIONS
Текущее число соединений для учетной записи.
TOTAL_CONNECTIONS
Общее количество соединений для учетной записи.
У accounts
есть эти индексы:
Первичный ключ на (USER
, HOST
).
Таблица hosts
содержит строку для каждого узла, с которого клиенты соединились с сервером
MySQL. Для каждого имени хоста таблица считает текущее и общее количество
соединений. Табличный размер задан при запуске сервера. Чтобы установить
табличный размер явно, установите системную переменную
performance_schema_hosts_size
при запуске сервера.
Чтобы отключить статистику учетной записи, установите эту переменную в 0.
Таблица hosts
имеет следующие столбцы. Для описания того, как Performance Schema
поддерживает строки в этой таблице, включая эффект
TRUNCATE TABLE
, см.
раздел 23.9.8.
HOST
Узел, от которого соединялся клиент. Это NULL
для внутреннего потока или для пользовательского сеанса, который был не в
состоянии подтвердить подлинность.
CURRENT_CONNECTIONS
Текущее число соединений для учетной записи.
TOTAL_CONNECTIONS
Общее количество соединений для учетной записи.
У hosts
есть эти индексы:
Первичный ключ на (HOST
).
Таблица users
содержит строку для каждого пользователя, который соединился с сервером
MySQL. Для каждого имени пользователя таблица считает текущее и общее
количество соединений. Табличный размер задан при запуске сервера. Чтобы
установить табличный размер явно, установите переменную
performance_schema_users_size
при запуске сервера. Чтобы отключить
пользовательскую статистику, установите эту переменную в 0.
У таблицы users
есть следующие столбцы. Для описания того, как Performance Schema
поддерживает строки в этой таблице, включая эффект
TRUNCATE TABLE
, см.
раздел 23.9.8.
HOST
Узел, от которого соединялся клиент. Это NULL
для внутреннего потока или для пользовательского сеанса, который был не в
состоянии подтвердить подлинность.
CURRENT_CONNECTIONS
Текущее число соединений для учетной записи.
TOTAL_CONNECTIONS
Общее количество соединений для учетной записи.
У users
есть эти индексы:
Первичный ключ на (USER
).
Приложения могут предоставить пары ключ/значение как атрибуты соединения
для передачи серверу во время соединения. Для C API определите набор
признака, используя функции
mysql_options()
и
mysql_options4()
.
Другие MySQL Connector могут обеспечить свои собственные методы определения.
Эти таблицы выставляют информацию атрибута:
session_account_connect_attrs
:
Признаки соединения для текущего сеанса и других сеансов, связанных
с учетной записью сеанса.
session_connect_attrs
: Признаки соединения для всех сеансов.
Названия атрибутов, которые начинаются с подчеркивания
(_
), сохранены для внутреннего пользования и не должен быть
созданы приложениями. Это соглашение разрешает новым признакам быть
введенными MySQL, не сталкиваясь с признаками приложения.
Набор признаков соединения, видимых в данном соединении, изменяется в зависимости от Вашей платформы и MySQL Connector, которым установили соединение.
Библиотека клиента libmysqlclient
(обеспечена в
MySQL и MySQL Connector/C) устанавливает эти признаки:
_client_name
:
Имя клиента (libmysql
для библиотеки клиента).
_client_version
: Версия библиотеки клиента._os
: Операционная система (например,
Linux
, Win64
)._pid
: ID процесса клиента._platform
: Машинная платформа (например,
x86_64
)._thread
: ID потока клиента (только под Windows).
Прочие MySQL Connector могут определить свои собственные признаки соединения.
MySQL Connector/J определяет эти признаки:
_client_license
: Тип лицензии соединителя.
_runtime_vendor
: Поставщик Java runtime environment (JRE).
_runtime_version
: Версия Java runtime environment (JRE).
MySQL Connector/Net определяет эти признаки:
_client_version
: Версия библиотеки клиента.
_os
: Операционная система (например,
Linux
, Win64
)._pid
: ID процесса клиента._platform
: Машинная платформа (например,
x86_64
)._program_name
: Имя клиента._thread
: ID потока клиента (только под Windows).
PHP определяет признаки, которые зависят от того, как он был собран:
Собран с применением libmysqlclient
:
признаки libmysqlclient
, описанные ранее.
mysqlnd
: только признак
_client_name
со значением mysqlnd
.Много программ клиента MySQL устанавливают признак
program_name
со значением, равным имени клиента. Например,
mysqladmin
и mysqldump
устанавливают program_name
в
mysqladmin
и mysqldump
, соответственно.
Некоторые программы клиента MySQL определяют дополнительные признаки:
mysqlbinlog
определяет _client_role
как
binary_log_listener
.
program_name
как mysqld
, _client_role
как binary_log_listener
и
_client_replication_channel_name
как название канала.FEDERATED
определяют program_name
как mysqld
и
_client_role
как federated_storage
.Есть пределы на количестве данных о признаке соединения, переданных от клиента к серверу: фиксированный предел наложен клиентом до времени соединения, фиксированный предел наложен сервером во время соединения и конфигурируемый предел наложен Performance Schema во время соединения.
Для соединений, начатых, используя C API, библиотека
libmysqlclient
налагает предел 64 КБ на совокупный размер данных
о признаке соединения по стороне клиента: вызовы
mysql_options()
, которые
превышают этот предел, производят ошибку
CR_INVALID_PARAMETER_NO
. Другие MySQL Connector
могут наложить свои собственные клиентские пределы на то, сколько данных о
признаке соединения может быть передано серверу.
На стороне сервера данные о признаке соединения проверяются так:
Сервер налагает предел 64 КБ на совокупный размер данных о
признаке соединения, который примет. Если клиент пытается послать больше
64 КБ данных о признаке, сервер отклоняет соединение. Иначе, сервер полагает,
что признак допустимый и отслеживает размер самого длинного буфера признака
в статусной переменной
Performance_schema_session_connect_attrs_longest_seen
.
performance_schema_session_connect_attrs_size
.
Если размер признака превышает это значение, эти действия имеют место:
Performance Schema усекает данные о признаке и увеличивает
переменную
Performance_schema_session_connect_attrs_lost
, которая
указывает число соединений, для которых произошло усечение признака.
log_warnings
больше, чем ноль:
Connection attributes of lengthN
were truncated (N
bytes lost) for connectionN
, useruser_name
@host_name
(asuser_name
), auth: {yes|no}
Информация в предупреждающем сообщении предназначена, чтобы помочь DBA идентифицировать клиентов, для которых произошло усечение признака.
_truncated
добавлен к признакам сеанса со значением,
указывающим, сколько байтов было потеряно, если у буфера признака есть
достаточное пространство. Это позволяет Performance Schema выставить
информацию об усечении на соединение в таблицах атрибутов соединения.
Эта информация может быть исследована, не имея необходимости
проверять журнал ошибок.Приложения могут обеспечить признаки соединения ключа/значения,
которые передадут к серверу во время соединения, используя функции C API
the mysql_options()
и
mysql_options4()
.
session_account_connect_attrs
содержит признаки соединения только для сеансов для Вашей собственной учетной
записи. Чтобы видеть признаки соединения для всех сеансов, загляните в
session_connect_attrs
.
У
session_account_connect_attrs
есть эти столбцы:
PROCESSLIST_ID
Идентификатор соединения для сеанса.
ATTR_NAME
Название атрибута.
ATTR_VALUE
Значение атрибута.
ORDINAL_POSITION
Порядок, в котором признак был добавлен к набору признаков соединения.
У
session_account_connect_attrs
есть эти индексы:
Первичный ключ на (PROCESSLIST_ID
,
ATTR_NAME
).
TRUNCATE TABLE
не
позволен для
session_account_connect_attrs
.
Приложения могут обеспечить признаки соединения ключа/значения, которые
передадут серверу во время соединения, используя функции C API
the mysql_options()
и
mysql_options4()
.
session_connect_attrs
содержит признаки соединения для всех
сеансов. Чтобы видеть признаки соединения сеансов только для Вашей
собственной учетной записи, загляните в
session_account_connect_attrs
.
У
session_connect_attrs
есть эти столбцы:
PROCESSLIST_ID
Идентификатор соединения для сеанса.
ATTR_NAME
Название атрибута.
ATTR_VALUE
Значение атрибута.
ORDINAL_POSITION
Порядок, в котором признак был добавлен к набору признаков соединения.
У
session_connect_attrs
есть эти индексы:
Первичный ключ на (PROCESSLIST_ID
,
ATTR_NAME
).
TRUNCATE TABLE
не
позволен для
session_connect_attrs
.
Performance Schema обеспечивает таблицу
user_variables_by_thread
, которая выставляет определяемые
пользователем переменные. Это переменные, определенные в пределах
определенного сеанса, и включают символ @
, предшествующий имени.
У
user_variables_by_thread
есть эти столбцы:
THREAD_ID
Идентификатор потока сеанса, в котором определена переменная.
VARIABLE_NAME
Имя переменной без символа @
.
VARIABLE_VALUE
Значение переменной.
У
user_variables_by_thread
есть эти индексы:
Первичный ключ на (THREAD_ID
,
VARIABLE_NAME
).
TRUNCATE TABLE
не
позволен для
user_variables_by_thread
.
Performance Schema обеспечивает таблицы, которые выставляют информацию о
репликации. Это подобно информации, доступной от
SHOW SLAVE STATUS
,
но представление в табличной форме более доступно и обладает преимуществами
удобства и простоты использования:
Вывод SHOW SLAVE STATUS
полезен для визуального осмотра, но не для использования с
программным управлением. В отличие от этого, используя таблицы Performance
Schema, информация о ведомом состоянии может искаться, используя общие
запросы SELECT
, включая комплексные
условия WHERE
, соединения и т.д.
SHOW
SLAVE STATUS
показывает все ошибки потоков, используя поля
Last_SQL_Errno
и Last_SQL_Error
,
таким образом, только последняя из этих ошибок видима, и информация может
быть потеряна. Таблицы репликации хранят ошибки на основе потока
без потери информации.SHOW SLAVE STATUS
.Performance Schema обеспечивает несколько связанных таблиц:
Таблицы, которые содержат информацию о присоединении ведомого сервера к главному серверу:
replication_connection_configuration
: Параметры конфигурации
для того, чтобы соединиться с ведущим устройством.
replication_connection_status
:
Текущий статус соединения с ведущим устройством.Таблицы, которые содержат общую (не определенную для потока) информацию о транзакци:
replication_applier_configuration
:
Параметры конфигурации для транзакции на ведомом устройстве.
replication_applier_status
:
Текущий статус транзакции на ведомом устройстве.Таблицы, которые содержат информацию об определенных потоках, ответственных за применение транзакций, полученных от ведущего устройства:
replication_applier_status_by_coordinator
:
Состояние (SQL или координатор) потока.
replication_applier_status_by_worker
:
Состояние рабочего потока (пустой, если ведомое устройство
не является мультипоточным).Таблицы, которые содержат информацию о членах группы:
replication_group_members
:
Предоставляет сетевую и информацию о статусе членов группы.
replication_group_member_stats
:
Предоставляет статистическую информацию о членах группы и транзакции,
в которой они участвуют.Следующие разделы описывают каждую таблицу более подробно, включая
связь между столбцами, произведенными
SHOW SLAVE STATUS
и столбцы таблицы репликации, в которых
появляется та же самая информация.
Остаток этого введения в таблицы описывает, как Performance Schema
заполняет их, и которые области от
SHOW SLAVE STATUS
не представлены в таблицах.
Performance Schema заполняет таблицы следующим образом:
До выполнения CHANGE
MASTER TO
таблицы пусты.
CHANGE MASTER TO
параметры конфигурации могут быть замечены в таблицах. В это время нет
никаких активных ведомых потоков, таким образом, столбцы
THREAD_ID
NULL
и SERVICE_STATE
OFF
.START SLAVE
,
THREAD_ID
не NULL
. У потоков, которые спят или
активны, есть SERVICE_STATE
ON
.
У потока, который соединяется с главным сервером, есть значение
CONNECTING
в то время, как это устанавливает соединение, и
ON
после этого, пока соединение длится.STOP SLAVE
THREAD_ID
NULL
и у столбцов SERVICE_STATE
для потоков, которые больше не существуют, OFF
.STOP
SLAVE
или потоков с ошибками.replication_applier_status_by_worker
непуста только, когда ведомое устройство работает в виде мультидерева
сообщений. Таким образом, если системная переменная
slave_parallel_workers
больше 0, эта таблица заполнена, когда
выполнен START SLAVE
, число
строк показывает количество рабочих процессов.Информация в таблицах Performance Schema несколько отличается от
информации, доступной от SHOW SLAVE
STATUS
потому? что таблицы ориентируются на использование
глобальных операционных идентификаторов (GTID), а не имен файла и позиций, и
они представляют серверные значения UUID, а не значения ID сервера.
Из-за этих различий, несколько столбцов
SHOW SLAVE STATUS
не сохранены в Performance Schema или
представлены иным путем:
Следующие области обращаются к именам файла и позициям и не сохранены:
Master_Log_File Read_Master_Log_Pos Relay_Log_File Relay_Log_Pos Relay_Master_Log_File Exec_Master_Log_Pos Until_Condition Until_Log_File Until_Log_Pos
Master_Info_File
не сохранено. Это обращается к
файлу master.info
, который был заменен безопасными для
катастрофического отказа ведомыми таблицами.server_id
, а не
server_uuid
и не сохранены:
Master_Server_Id Replicate_Ignore_Server_Ids
Skip_Counter
основано на количестве
событий, а не GTID и не сохранено.Last_SQL_Errno
и Last_SQL_Error
,
таким образом, они не сохранены:
Last_Errno Last_Error
В Performance Schema эта информация об ошибке доступна в столбцах
LAST_ERROR_NUMBER
и LAST_ERROR_MESSAGE
таблицы
replication_applier_status_by_coordinator
(и
replication_applier_status_by_worker
,
если ведомое устройство является мультипоточным). Те таблицы предоставляют
более определенную информацию об ошибке для потока, чем доступна от
Last_Errno
и Last_Error
.
Replicate_Do_DB Replicate_Ignore_DB Replicate_Do_Table Replicate_Ignore_Table Replicate_Wild_Do_Table Replicate_Wild_Ignore_Table
Slave_IO_State
и
Slave_SQL_Running_State
не сохранены. Если нужно, эти значения
могут быть получены из списка процессов при использовании столбца
THREAD_ID
соответствующей таблицы и присоединения к этому
столбца ID
таблицы INFORMATION_SCHEMA
PROCESSLIST
, чтобы
выбрать столбец STATE
последней таблицы.Executed_Gtid_Set
может показать большой набор с
большим количеством текста. Вместо этого таблицы Performance Schema
показывают GTID транзакций, которые в настоящее время применяются ведомым
устройством. Альтернативно, набор выполненного GTID может быть получен из
значения переменной
gtid_executed
.Seconds_Behind_Master
и
Relay_Log_Space
не сохранены.Начиная с MySQL 5.7.5, следующие переменные состояния (ранее доступные
через использование SHOW STATUS
) были перемещены в таблицы Perfomance Schema:
Эти переменные состояния теперь релевантны только, когда применяется единственный канал репликации, потому что они сообщают о состоянии только каналапо умолчанию. Когда много каналов существует, используйте таблицы Performance Schema, описанные в этом разделе, которые сообщают об этих переменных для каждого существующего канала.
Первый столбец таблиц Performance Schema CHANNEL_NAME
.
Это позволяет таблицам рассматриваться по каналам. Когда Вы используете
многократные каналы на ведомом устройстве, Вы можете фильтровать таблицы по
каналам, чтобы контролировать определенный канал. См. разделы
19.2.3 и
19.1.4.3.
Эта таблица показывает параметры конфигурации, используемые ведомым
сервером для того, чтобы соединиться с главным сервером. Параметры,
сохраненные в таблице, могут быть изменены во время выполнения с помощью
CHANGE MASTER TO
,
как обозначено в описаниях столбца.
По сравнению с
replication_connection_status
,
replication_connection_configuration
изменяется менее часто. Это содержит значения, которые определяют, как
ведомое устройство соединяется с ведущим и которые остаются постоянными во
время соединения, тогда как
replication_connection_status
содержит значения, которые изменяются во время соединения.
У
replication_connection_configuration
есть эти столбцы:
CHANNEL_NAME
Канал, который эта строка отображает. Всегда есть канал по умолчанию, и больше каналов может быть добавлено. См. раздел 19.2.3.
HOST
Основной узел, с которым соединено ведомое устройство.
(CHANGE MASTER TO
опция MASTER_HOST
).
PORT
Порт для связи с ведущим устройством. (CHANGE
MASTER TO
опция MASTER_PORT
).
USER
Имя пользователя учетной записи для связи с ведущим устройством.
(CHANGE MASTER TO
опция MASTER_USER
).
NETWORK_INTERFACE
Сетевой интерфейс для связи, если есть.
(CHANGE MASTER TO
опция MASTER_BIND
).
AUTO_POSITION
1, если авторасположение используется, иначе 0.
(CHANGE MASTER TO
опция MASTER_AUTO_POSITION
).
SSL_ALLOWED
, SSL_CA_FILE
,
SSL_CA_PATH
, SSL_CERTIFICATE
,
SSL_CIPHER
, SSL_KEY
,
SSL_VERIFY_SERVER_CERTIFICATE
,
SSL_CRL_FILE
, SSL_CRL_PATH
Эти столбцы показывают параметры SSL, используемые ведомым устройством, чтобы соединиться с ведущим, если они есть.
SSL_ALLOWED
имеет эти значения:
Yes
если соединение SSL с
ведущим устройством разрешено.
No
, если соединение SSL с ведущим устройством не разрешено.
Ignored
, если соединение SSL разрешено, но у ведомого сервера
нет включенной поддержки SSL.Опции CHANGE MASTER TO
для других столбцов SSL:
MASTER_SSL_CA
, MASTER_SSL_CAPATH
,
MASTER_SSL_CERT
, MASTER_SSL_CIPHER
,
MASTER_SSL_CRL
, MASTER_SSL_CRLPATH
,
MASTER_SSL_KEY
, MASTER_SSL_VERIFY_SERVER_CERT
.
CONNECTION_RETRY_INTERVAL
Число секунд между повторами соединения.
(CHANGE MASTER TO
опция MASTER_CONNECT_RETRY
).
CONNECTION_RETRY_COUNT
Число раз, которое ведомое устройство может попытаться повторно
соединиться с ведущим устройством в случае потерянного соединения.
(CHANGE MASTER TO
опция MASTER_RETRY_COUNT
).
HEARTBEAT_INTERVAL
Интервал биения репликации на ведомом устройстве в секундах.
У
replication_connection_configuration
есть эти индексы:
Первичный ключ на (CHANNEL_NAME
).
TRUNCATE TABLE
не
позволен для
replication_connection_configuration
.
Следующая таблица показывает связь между столбцами
replication_connection_configuration
и
SHOW SLAVE STATUS
.
Столбец replication_connection_configuration
| Столбец SHOW SLAVE STATUS |
---|---|
HOST | Master_Host
|
PORT | Master_Port |
USER | Master_User |
NETWORK_INTERFACE | Master_Bind
|
AUTO_POSITION | Auto_Position
|
SSL_ALLOWED | Master_SSL_Allowed
|
SSL_CA_FILE | Master_SSL_CA_File
|
SSL_CA_PATH | Master_SSL_CA_Path
|
SSL_CERTIFICATE |
Master_SSL_Cert |
SSL_CIPHER | Master_SSL_Cipher
|
SSL_KEY | Master_SSL_Key
|
SSL_VERIFY_SERVER_CERTIFICATE |
Master_SSL_Verify_Server_Cert |
SSL_CRL_FILE | Master_SSL_Crl
|
SSL_CRL_PATH |
Master_SSL_Crlpath |
CONNECTION_RETRY_INTERVAL |
Connect_Retry |
CONNECTION_RETRY_COUNT |
Master_Retry_Count |
Эта таблица показывает текущий статус потока ввода/вывода, который обрабатывает ведомое соединение сервера с главным сервером.
По сравнению с
replication_connection_configuration
,
replication_connection_status
изменяется более часто. Это содержит
значения, которые изменяются во время соединения, тогда как
replication_connection_configuration
содержит значения, которые определяют, как ведомое устройство соединяется с
ведущим и которые остаются постоянными во время соединения.
У
replication_connection_status
есть эти столбцы:
CHANNEL_NAME
Канал, который эта строка отображает. Всегда есть канал по умолчанию, и больше каналов может быть добавлено. См. раздел 19.2.3.
GROUP_NAME
Этот столбец сохранен для будущего использования.
SOURCE_UUID
server_uuid
от ведущего устройства.
THREAD_ID
ID потока I/O.
SERVICE_STATE
ON
(поток существует и является активным или спящим),
OFF
(поток больше не существует) или CONNECTING
(поток существует и соединяется с ведущим устройством).
RECEIVED_TRANSACTION_SET
Набор глобальных операционных ID (GTID), соответствующий всем транзакциям, полученным этим ведомым устройством. Пустой, если GTID не используются.
LAST_ERROR_NUMBER
, LAST_ERROR_MESSAGE
Код ошибки и сообщение об ошибке, которая заставила поток ввода/вывода
останавливаться. Код ошибки 0 и пустая строка не означают отсутствие ошибок.
Если LAST_ERROR_MESSAGE
не пусто,
ошибочные значения также появляются в журнале ошибок ведомого устройства.
RESET MASTER
или
RESET SLAVE
сбрасывает значения, показанные в этих столбцах.
LAST_ERROR_TIMESTAMP
timestamp в формате YYMMDD HH:MM:SS
, который показывает,
когда последняя ошибка ввода/вывода имела место.
LAST_HEARTBEAT_TIMESTAMP
timestamp в формате YYMMDD HH:MM:SS
, который показывает,
когда последний сигнал биения был получен ведомым устройством.
COUNT_RECEIVED_HEARTBEATS
Общее количество сигналов биения, которые ведомое устройство
получило с прошлого перезапуска или запроса
CHANGE MASTER TO
.
У
replication_connection_status
есть эти индексы:
Первичный ключ на (CHANNEL_NAME
).
THREAD_ID
).TRUNCATE TABLE
не
позволен для
replication_connection_status
.
Следующая таблица показывает связь между столбцами
replication_connection_status
и
SHOW SLAVE STATUS
.
Столбец replication_connection_status
| Столбец SHOW SLAVE STATUS |
---|---|
SOURCE_UUID | Master_UUID
|
THREAD_ID | Нет |
SERVICE_STATE | Slave_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 |
Таблица показывает параметры конфигурации, примененные ведомым сервером.
Параметры, сохраненные в таблице, могут быть изменены во время выполнения с
помощью CHANGE MASTER TO
,
как обозначено в описаниях столбца.
У
replication_applier_configuration
есть эти столбцы:
CHANNEL_NAME
Канал, который эта строка отображает. Всегда есть канал по умолчанию, и больше каналов может быть добавлено. См. раздел 19.2.3.
DESIRED_DELAY
Число секунд, которые ведомое устройство должно
изолировать ведущее устройство. (CHANGE MASTER TO
опция
MASTER_DELAY
).
У
replication_applier_configuration
есть эти индексы:
Первичный ключ на (CHANNEL_NAME
).
TRUNCATE TABLE
не
позволен для
replication_applier_configuration
.
Следующая таблица показывает связь между столбцами
replication_applier_configuration
и
SHOW SLAVE STATUS
.
Столбец replication_applier_configuration
|
Столбец SHOW SLAVE STATUS |
---|---|
DESIRED_DELAY |
SQL_Delay |
Эта таблица показывает текущее общее операционное состояние выполнения на ведомом сервере.
Эта таблица предоставляет информацию об общих аспектах транзакции, которые
не являются определенными для любого вовлеченного потока. Определенная для
потока информация о статусе доступна в
replication_applier_status_by_coordinator
(и
replication_applier_status_by_worker
,
если ведомое устройство является мультипоточным).
У
replication_applier_status
есть эти столбцы:
CHANNEL_NAME
Канал, который эта строка отображает. Всегда есть канал по умолчанию, и больше каналов может быть добавлено. См. раздел 19.2.3.
SERVICE_STATE
Сохранено для будущего использования.
REMAINING_DELAY
Если ведомое устройство ждет DESIRED_DELAY
секунд, так как ведущее устройство применяет случай, это поле содержит
оставшееся число секунд задержки. В других случаях это NULL
.
DESIRED_DELAY
сохранено в
replication_applier_configuration
.
COUNT_TRANSACTIONS_RETRIES
Показывает число повторений, которые были сделаны, потому что ведомый поток SQL был не в состоянии применить транзакцию.
У
replication_applier_status
есть эти индексы:
Первичный ключ на (CHANNEL_NAME
).
TRUNCATE TABLE
не
позволен для
replication_applier_status
.
Следующая таблица показывает связь между
replication_applier_status
и
SHOW SLAVE STATUS
.
Столбец replication_applier_status
|
Столбец SHOW SLAVE STATUS |
---|---|
SERVICE_STATE | Нет |
REMAINING_DELAY |
SQL_Remaining_Delay |
Для мультипоточного ведомого устройства ведомое устройство использует
много рабочих потоков и поток координатора, чтобы управлять ими. Эта таблица
показывает состояние потока координатора. Для однопоточного ведомого
устройства эта таблица пуста. Для мультипоточного ведомого устройства
replication_applier_status_by_worker
показывает состояние рабочих потоков.
У
replication_applier_status_by_coordinator
есть эти столбцы:
CHANNEL_NAME
Канал, который эта строка отображает. Всегда есть канал по умолчанию, и больше каналов может быть добавлено. См. раздел 19.2.3.
THREAD_ID
ID потока SQL/coordinator.
SERVICE_STATE
ON
(поток существует и является активным или спящим) или
OFF
(поток больше не существует).
LAST_ERROR_NUMBER
, LAST_ERROR_MESSAGE
Код ошибки и сообщение об ошибке, которая заставила поток SQL/coordinator
останавливаться. Код ошибки 0 и пустая строка не означают, что ошибки нет.
Если LAST_ERROR_MESSAGE
не пусто, ошибочные значения также
появляются в журнале ошибок ведомого устройства.
RESET MASTER
или
RESET SLAVE
сбрасывает значения, показанные в этих столбцах.
Все коды ошибки и сообщения в LAST_ERROR_NUMBER
и
LAST_ERROR_MESSAGE
соответствуют ошибочным значениям,
перечисленным в разделе B.3.
LAST_ERROR_TIMESTAMP
timestamp в формате YYMMDD HH:MM:SS
,
который показывает, когда последняя ошибка SQL/coordinator произошла.
У
replication_applier_status_by_coordinator
есть эти индексы:
Первичный ключ на (CHANNEL_NAME
).
THREAD_ID
).TRUNCATE TABLE
не
позволен для
replication_applier_status_by_coordinator
.
Следующая таблица показывает связь между
replication_applier_status_by_coordinator
и
SHOW SLAVE STATUS
.
Столбец
replication_applier_status_by_coordinator |
Столбец SHOW SLAVE STATUS |
---|---|
THREAD_ID | Нет |
SERVICE_STATE |
Slave_SQL_Running |
LAST_ERROR_NUMBER |
Last_SQL_Errno |
LAST_ERROR_MESSAGE |
Last_SQL_Error |
LAST_ERROR_TIMESTAMP |
Last_SQL_Error_Timestamp |
Если ведомое устройство не является мультипоточным, эта таблица показывает
состояние потока. Иначе, ведомое устройство использует много рабочих потоков
и поток координатора, чтобы управлять ими, и эта таблица показывает состояние
рабочих потоков. Для мультипоточного ведомого устройства
replication_applier_status_by_coordinator
показывает состояние потока координатора.
У replication_applier_status_by_worker
есть эти столбцы:
CHANNEL_NAME
Канал, который эта строка отображает. Всегда есть канал по умолчанию, и больше каналов может быть добавлено. См. раздел 19.2.3.
WORKER_ID
Идентификатор рабочего (то же самое значение, как столбец
id
в таблице mysql.slave_worker_info
).
После STOP SLAVE
THREAD_ID
становится NULL
, но
WORKER_ID
сохранено.
THREAD_ID
ID рабочего потока.
SERVICE_STATE
ON
(поток существует и является активным или спящим) или
OFF
(поток больше не существует).
LAST_SEEN_TRANSACTION
Транзакция, которую рабочий поток обработал последней. Рабочий поток не обязательно применил эту транзакцию, потому что она могла быть в процессе выполнения.
Если значение переменной
gtid_mode
OFF
, этот столбец ANONYMOUS
,
указывая, что транзакции не имеют глобальных операционных идентификаторов
(GTID) и идентифицированы только файлом и позицией.
Если gtid_mode
ON
, значение столбца определено следующим образом:
Если никакая транзакция не выполнена, столбец пуст.
gtid_next
.
С этого момента столбец всегда показывает GTID.gtid_next
вскоре после того, как
gtid_next
установлен.
LAST_ERROR_NUMBER
, LAST_ERROR_MESSAGE
Код ошибки и сообщение об ошибке, которая заставила поток
останавливаться. Код ошибки 0 и пустая строка не означают отсутствие ошибки.
Если LAST_ERROR_MESSAGE
не пусто, ошибочные значения также
появляются в журнале ошибок ведомого устройства.
RESET MASTER
или
RESET SLAVE
сбрасывает значения, показанные в этих столбцах.
Все коды ошибки и сообщения, выведенные на экран в
LAST_ERROR_NUMBER
и LAST_ERROR_MESSAGE
соответствуют ошибочным значениям, перечисленным в
разделе B.3.
LAST_ERROR_TIMESTAMP
timestamp в формате YYMMDD HH:MM:SS
, который показывает,
когда последняя ошибка рабочего потока произошла.
У
replication_applier_status_by_worker
есть эти индексы:
Первичный ключ на (CHANNEL_NAME
,
WORKER_ID
).
THREAD_ID
).TRUNCATE TABLE
не
позволен для
replication_applier_status_by_worker
.
Следующая таблица показывает связь между
replication_applier_status_by_worker
и
SHOW SLAVE STATUS
.
Столбец replication_applier_status_by_worker
|
Столбец SHOW SLAVE STATUS |
---|---|
WORKER_ID | Нет |
THREAD_ID | Нет |
SERVICE_STATE | Нет |
LAST_SEEN_TRANSACTION | Нет |
LAST_ERROR_NUMBER |
Last_SQL_Errno |
LAST_ERROR_MESSAGE |
Last_SQL_Error |
LAST_ERROR_TIMESTAMP |
Last_SQL_Error_Timestamp |
Эта таблица показывает сеть и информацию о статусе для членов группы репликации.
Таблица replication_group_members
имеет следующие столбцы:
CHANNEL_NAME
Название группового канала.
MEMBER_ID
Идентификатор для этого участника, то же самое как сервер UUID.
MEMBER_HOST
Сетевой адрес этого участника (имя хоста или IP-адрес).
MEMBER_PORT
Порт, на котором слушает сервер.
MEMBER_STATE
Текущее состояние этого участника, может быть любое из следующего:
OFFLINE
: Групповой плагин установлен, но
не был запущен.
RECOVERING
: Сервер присоединился к группе, от которой
он получает данные.ONLINE
: Участник находится в
полностью функционирующем статусе.TRUNCATE TABLE
не
позволен для
replication_group_members
.
Эта таблица показывает статистическую информацию для членов группы.
У replication_group_member_stats
есть следующие столбцы:
CHANNEL_NAME
Название группового канала.
VIEW_ID
Идентификатор текущего представления для этой группы.
MEMBER_ID
Идентификатор для этого участника, то же самое как сервер UUID.
COUNT_TRANSACTIONS_IN_QUEUE
Число транзакций в ожидании.
COUNT_TRANSACTIONS_CHECKED
Число транзакций уже удостоверено этим участником.
COUNT_CONFLICTS_DETECTED
Число транзакций, которые не были удостоверены.
COUNT_TRANSACTIONS_VALIDATING
Число транзакций, с которыми может выполниться удостоверение, но не был собран мусор.
TRANSACTIONS_COMMITTED_ALL_MEMBERS
Набор устойчивых групповых транзакций.
LAST_CONFLICT_FREE_TRANSACTION
Последняя транзакция, удостоверенная без конфликтов.
TRUNCATE TABLE
не
позволен для
replication_group_member_stats
.
Performance Schema выставляет информацию о блокировке через эти таблицы:
data_locks
:
Блокировки данных.
data_lock_waits
: Отношения между владельцами блокировок и просителями,
заблокированными этими владельцами.metadata_locks
: Блокировки метаданных.table_handles
:
Табличные блокировки.Следующие разделы описывают эти таблицы более подробно.
Таблица data_locks
показывает блокировки данных, которые введены и требуются. Для информации о
том, какие запросы блокировки заблокированы введеными блокировками, см.
раздел 23.9.12.2.
Обе таблицы были добавлены в MySQL 8.0.1.
Данные в качестве примера:
mysql> SELECT * FROM data_locks\G *************************** 1. row *************************** ENGINE: INNODB ENGINE_LOCK_ID: 4140:74 ENGINE_TRANSACTION_ID: 4140 THREAD_ID: 37 EVENT_ID: 9 OBJECT_SCHEMA: test OBJECT_NAME: t1 PARTITION_NAME: NULL SUBPARTITION_NAME: NULL INDEX_NAME: NULL OBJECT_INSTANCE_BEGIN: 140489308280888 LOCK_TYPE: TABLE LOCK_MODE: IX LOCK_STATUS: GRANTED LOCK_DATA: NULL *************************** 2. row *************************** ENGINE: INNODB ENGINE_LOCK_ID: 4140:66:5:1 ENGINE_TRANSACTION_ID: 4140 THREAD_ID: 37 EVENT_ID: 9 OBJECT_SCHEMA: test OBJECT_NAME: t1 PARTITION_NAME: NULL SUBPARTITION_NAME: NULL INDEX_NAME: GEN_CLUST_INDEX OBJECT_INSTANCE_BEGIN: 140489320307736 LOCK_TYPE: RECORD LOCK_MODE: X LOCK_STATUS: GRANTED LOCK_DATA: supremum pseudo-record
В отличие от большинства сбора данных Performance Schema, нет никаких инструментов для того, чтобы управлять, собрана ли информация о блокировках данных, или системных переменных для того, чтобы управлять табличными размерами блокировки данных. Performance Schema собирает информацию, которая уже доступна в сервере, таким образом нет никаких издержек памяти или центрального процессора, чтобы произвести эту информацию или потребности в параметрах, которые управляют ее сбором.
Используйте data_locks
, чтобы помочь диагностировать исполнительные проблемы, которые
происходят во времена тяжелой параллельной загрузки. Для InnoDB
см. обсуждение этой темы в
разделе 16.14.2
.
У data_locks
есть эти столбцы:
ENGINE
:
Механизм хранения, который держит или просил блокировку.
ENGINE_LOCK_ID
:
ID блокировки. Кортежи зачений
(ENGINE_LOCK_ID
, ENGINE
) уникальны.
Форматы ID блокировки являются внутренними и подлежат изменению в любое время. Приложения не должны положиться на ID блокировки, имеющие особый формат.
ENGINE_TRANSACTION_ID
:
Внутренний ID механизма хранения транзакции, которая просила блокировку.
Для InnoDB
, чтобы получить детали о транзакции,
присоединитесь к этому столбцу с TRX_ID
из
INFORMATION_SCHEMA
INNODB_TRX
.
THREAD_ID
:
ID потока, которому принадлежит блокировка. Чтобы получить детали о
потоке, присоединитесь к этому столбцу с THREAD_ID
из
Performance Schema threads
.
EVENT_ID
:
Исполнительный случай, который вызвал блокировку. Кортежи
(THREAD_ID
, EVENT_ID
) неявно идентифицируют
родительский случай в других таблицах Performance Schema:
Родительский случай ожидания в таблице
events_waits_
.xxx
events_stages_xxx
.events_statements_xxx
.events_transactions_xxx
.Чтобы получить детали о родительском случае, соедините столбцы
THREAD_ID
и EVENT_ID
со столбцами подобного имени в
соответствующей родительской таблице событий.
OBJECT_SCHEMA
:
Схема, которая содержит заблокированную таблицу.
OBJECT_NAME
:
Название заблокированной таблицы.
PARTITION_NAME
:
Название заблокированного разделения, если есть, иначе NULL
.
SUBPARTITION_NAME
:
Название заблокированного подразделения, если
есть, иначе NULL
.
INDEX_NAME
:
Название заблокированного индекса, если
есть, иначе NULL
.
Практически InnoDB
всегда создает индекс
(GEN_CLUST_INDEX
), так что INDEX_NAME
не NULL
для таблиц InnoDB
всегда.
OBJECT_INSTANCE_BEGIN
:
Адрес в памяти о блокировке.
LOCK_TYPE
:
Тип блокировки.
Значение зависит от механизма хранения. Для InnoDB
разрешенные значения RECORD
для блокировки на уровне строки и
TABLE
для блокировки на уровне таблицы.
LOCK_MODE
:
Как блокировку требуют.
Значение зависит от механизма хранения. Для InnoDB
разрешенные значения S[,GAP]
, X[,GAP]
,
IS[,GAP]
, IX[,GAP]
,
AUTO_INC
и UNKNOWN
. Режимы блокировки кроме
AUTO_INC
и UNKNOWN
указывают на блокировки промежутка, если существует. Для информации о
S
, X
, IS
, IX
и блокировке промежутка, обратитесь к
разделу 16.5.1.
LOCK_STATUS
:
Состояние запроса блокировки.
Значение зависит от механизма хранения. Для InnoDB
разрешенные значения GRANTED
(блокировка проводится) и
PENDING
(блокировку ждут).
LOCK_DATA
:
Данные связанные с блокировкой, если есть.
Значение зависит от механизма хранения. Для InnoDB
это значения первичного ключа заблокированной записи, если
LOCK_TYPE
RECORD
, иначе NULL
.
Этот столбец содержит значения столбцов первичного ключа в заблокированной
строке, отформатированной как допустимая строка SQL (готовая, чтобы быть
скопированной в запрос SQL). Если нет никакого первичного ключа,
LOCK_DATA
уникальный внутренний идентификационный номер строки.
InnoDB
. Если блокировка промежутка взята для значений ключа или
диапазонов выше самого большого значения в индексировании,
LOCK_DATA
сообщает "supremum pseudo-record
".
Когда страница, содержащая заблокированную запись, не находится в буферном
бассейне (в случае, когда страницы были выгружены на диск в то время, как
блокировка проводилась), InnoDB
не грузит страницу с
диска, чтобы избежать ненужных дисковых операций. Вместо этого
LOCK_DATA
установлен в NULL
.
У data_locks
есть эти индексы:
Первичный ключ на (ENGINE_LOCK_ID
,
ENGINE
).
ENGINE_TRANSACTION_ID
,
ENGINE
).THREAD_ID
, EVENT_ID
).OBJECT_SCHEMA
, OBJECT_NAME
,
PARTITION_NAME
, SUBPARTITION_NAME
).TRUNCATE TABLE
не
позволен для data_locks
.
Таблица data_lock_waits
осуществляет отношения, показывая, какие данные запирают запросы
в data_locks
,
сдерживая блокировки данных. Сдержанные блокировки в
data_locks
отобразятся в
data_lock_waits
только, если они блокируют некоторый запрос
блокировки. Обе таблицы были добавлены в MySQL 8.0.1.
Эта информация позволяет Вам понять зависимости от блокировки данных между сеансами. Таблица выставляет не только, которые блокировки держат сеанс, или какую блокировку ждет транзакция, но и то, какая сессия или транзакция в настоящее время проводят ту блокировку.
Блокировка данных в качестве примера:
mysql> SELECT * FROM data_lock_waits\G *************************** 1. row *************************** ENGINE: INNODB REQUESTING_ENGINE_LOCK_ID: 4141:66:5:2 REQUESTING_ENGINE_TRANSACTION_ID: 4141 REQUESTING_THREAD_ID: 38 REQUESTING_EVENT_ID: 11 REQUESTING_OBJECT_INSTANCE_BEGIN: 140489320441368 BLOCKING_ENGINE_LOCK_ID: 4140:66:5:2 BLOCKING_ENGINE_TRANSACTION_ID: 4140 BLOCKING_THREAD_ID: 37 BLOCKING_EVENT_ID: 9 BLOCKING_OBJECT_INSTANCE_BEGIN: 140489320307736
В отличие от большинства сбора данных Performance Schema, нет никаких инструментов для того, чтобы управлять, собрана ли информация о блокировках данных, или системных переменных для того, чтобы управлять табличными размерами блокировки данных. Performance Schema собирает информацию, которая уже доступна в сервере, таким образом нет никаких издержек памяти или центрального процессора, чтобы произвести эту информацию или потребности в параметрах, которые управляют ее сбором.
Используйте data_locks
, чтобы помочь диагностировать исполнительные проблемы, которые
происходят во времена тяжелой параллельной загрузки. Для InnoDB
см. обсуждение этой темы в
разделе 16.14.2
.
Поскольку столбцы в
data_lock_waits
подобны столбцам в
data_locks
,
описания столбцов здесь сокращены. Для более подробных описаний столбцов см.
раздел 23.9.12.1.
У data_lock_waits
есть эти столбцы:
ENGINE
Механизм хранения, который запросил блокировку.
REQUESTING_ENGINE_LOCK_ID
ID блокировки, которую требует механизм хранения. Чтобы получить детали о
блокировке, присоедините к этому столбцу LOCK_ID
из
data_locks
.
REQUESTING_ENGINE_TRANSACTION_ID
Внутренний ID механизма хранения транзакции, который запросил блокировку.
REQUESTING_THREAD_ID
ID потока сеанса, который запросил блокировку.
REQUESTING_EVENT_ID
Случай Performance Schema, который вызвал запрос блокировки в сеансе, который запросил блокировку.
REQUESTING_OBJECT_INSTANCE_BEGIN
Адрес в памяти о требуемой блокировке.
BLOCKING_ENGINE_LOCK_ID
ID блокировки. Чтобы получить детали о блокировке, присоединитесь к этому
столбцу с LOCK_ID
из
data_locks
.
BLOCKING_ENGINE_TRANSACTION_ID
Внутренний ID механизма хранения транзакции, которая держит блокировку.
BLOCKING_THREAD_ID
ID потока сеанса, который держит блокировку.
BLOCKING_EVENT_ID
Случай Performance Schema, который вызвал блокировку в сеансе.
BLOCKING_OBJECT_INSTANCE_BEGIN
Адрес в памяти о блокировке.
У
data_lock_waits
есть эти индексы:
Индекс на (REQUESTING_ENGINE_LOCK_ID
,
ENGINE
).
BLOCKING_ENGINE_LOCK_ID
,
ENGINE
).REQUESTING_ENGINE_TRANSACTION_ID
,
ENGINE
).BLOCKING_ENGINE_TRANSACTION_ID
,
ENGINE
).REQUESTING_THREAD_ID
,
REQUESTING_EVENT_ID
).BLOCKING_THREAD_ID
,
BLOCKING_EVENT_ID
).TRUNCATE TABLE
не
позволен для data_lock_waits
.
Performance Schema выставляет информацию о блокировке метаданных через
metadata_locks
:
Блокировки, которые предоставили.
Эта информация позволяет Вам понять зависимости от блокировки метаданных между сеансами. Вы можете видеть не только, которые блокировки сеанс ждет, но и какая сессия в настоящее время проводит эту блокировку.
metadata_locks
только для чтения и не может быть обновлена. Это задано по умолчанию, чтобы
сконфигурировать табличный размер, установите системную переменную
performance_schema_max_metadata_locks
при запуске сервера.
Инструментовка блокировки метаданных отключена по умолчанию. Чтобы
включить, запустите инструмент wait/lock/metadata/sql/mdl
в
setup_instruments
.
Performance Schema поддерживает табличный контент
metadata_locks
следующим образом, используя столбец LOCK_STATUS
, чтобы указать
на состояние каждой блокировки:
Когда блокировку метаданных требуют и немедленно получают, строка
с состоянием GRANTED
вставлена.
PENDING
вставлена.GRANTED
.
ER_LOCK_DEADLOCK
), состояние строки обновлено от
PENDING
до VICTIM
.ER_LOCK_WAIT_TIMEOUT
), состояние строки обновлено от PENDING
до
TIMEOUT
.GRANTED
или
PENDING
до KILLED
.VICTIM
, TIMEOUT
и KILLED
кратки и показывают, что строка блокировки собирается быть удаленной.PRE_ACQUIRE_NOTIFY
и
POST_RELEASE_NOTIFY
кратки и показывают, что подсистема
блокировки метаданных регистрирует заинтересованные механизмы хранения, вводя
приобретение блокировки или оставляя операции выпуска блокировки.
У metadata_locks
есть эти столбцы:
OBJECT_TYPE
Тип блокировки, использованный в подсистеме блокировки метаданных,
значение одно из GLOBAL
, SCHEMA
,
TABLE
, FUNCTION
, PROCEDURE
,
TRIGGER
(сейчас не используется), EVENT
,
COMMIT
, USER LEVEL LOCK
, TABLESPACE
или LOCKING SERVICE
.
Значение USER LEVEL LOCK
указывает на блокировку,
приобретенную с GET_LOCK()
. Значение LOCKING SERVICE
указывает, что блокировка
приобреталась с использованием службы блокировки, описанной в
разделе 26.3.1.
OBJECT_SCHEMA
Схема, которая содержит объект.
OBJECT_NAME
Название инструментованного объекта.
OBJECT_INSTANCE_BEGIN
Адрес в памяти об инструментованном объекте.
LOCK_TYPE
Тип блокировки от подсистемы метаданных блокировок. Значение одно из
INTENTION_EXCLUSIVE
, SHARED
,
SHARED_HIGH_PRIO
, SHARED_READ
,
SHARED_WRITE
, SHARED_UPGRADABLE
,
SHARED_NO_WRITE
, SHARED_NO_READ_WRITE
или
EXCLUSIVE
.
LOCK_DURATION
Продолжительность блокировки от подсистемы метаданных блокировок.
Значение одно из STATEMENT
, TRANSACTION
или
EXPLICIT
. STATEMENT
и TRANSACTION
для блокировок, которые выпущены в запросе или операционном конце,
соответственно. EXPLICIT
значение для блокировок, которые
переживают запрос или конец транзакции и выпущены явно, такие как глобальные
блокировки, приобретенные с FLUSH TABLES WITH
READ LOCK
.
LOCK_STATUS
Состояние блокировки от подсистемы метаданных блокировок.
Значение одно из PENDING
, GRANTED
,
VICTIM
, TIMEOUT
, KILLED
,
PRE_ACQUIRE_NOTIFY
или POST_RELEASE_NOTIFY
.
Performance Schema назначает эти значения как описано ранее в этом разделе.
SOURCE
Название исходного файла, содержащего инструментованный код, который произвел случай и номер строки в файле, в котором происходит инструментовка. Это позволяет Вам проверить источник, чтобы определить точно, какой код вовлечен.
OWNER_THREAD_ID
Поток, просящий блокировку метаданных.
OWNER_EVENT_ID
Случай, просящий блокировку метаданных.
У metadata_locks
есть эти индексы:
Первичный ключ на (OBJECT_INSTANCE_BEGIN
).
OBJECT_TYPE
, OBJECT_SCHEMA
,
OBJECT_NAME
).OWNER_THREAD_ID
, OWNER_EVENT_ID
).
TRUNCATE TABLE
не
позволен для metadata_locks
.
Performance Schema выставляет табличную информацию о блокировке через
table_handles
,
чтобы показать табличную блокировку в настоящее время в действительности для
каждого открытого табличного дескриптора.
table_handles
сообщает, что зарегистрировано табличной инструментовкой блокировки. Это
показывает, какая таблица открыта сервером, как она
заблокирована и которым сеансом.
table_handles
только для чтения и не может быть обновлена. Это задано по умолчанию, чтобы
сконфигурировать табличный размер, установите переменную
performance_schema_max_table_handles
при запуске сервера.
У table_handles
есть эти столбцы:
OBJECT_TYPE
Таблица открылась табличным дескриптором.
OBJECT_SCHEMA
Схема, которая содержит объект.
OBJECT_NAME
Название инструментованного объекта.
OBJECT_INSTANCE_BEGIN
Табличный дескриптор в памяти.
OWNER_THREAD_ID
Поток, имеющий табличный дескриптор.
OWNER_EVENT_ID
Случай, который заставил табличный дескриптор быть открытым.
INTERNAL_LOCK
Табличная блокировка на уровне SQL. Значение одно из
READ
, READ WITH SHARED LOCKS
,
READ HIGH PRIORITY
, READ NO INSERT
,
WRITE ALLOW WRITE
, WRITE CONCURRENT INSERT
,
WRITE LOW PRIORITY
или WRITE
.
Для информации об этих типах блокировки см. файл исходных текстов
include/thr_lock.h
.
EXTERNAL_LOCK
Табличная блокировка на уровне механизма хранения. Значение одно из
READ EXTERNAL
или WRITE EXTERNAL
.
У table_handles
есть эти индексы:
Первичный ключ на (OBJECT_INSTANCE_BEGIN
).
OBJECT_TYPE
, OBJECT_SCHEMA
,
OBJECT_NAME
).OWNER_THREAD_ID
, OWNER_EVENT_ID
).
TRUNCATE TABLE
не
позволен для table_handles
.
Значение переменной
show_compatibility_56
затрагивает информацию, доступную из
таблиц
global_variables
,
session_variables
и
variables_by_thread
, описанных здесь
(variables_info
не затронута). Для деталей см. описание той переменной в
разделе 6.1.5.
MySQL server поддерживает много системных переменных, которые указывают, как он сконфигурирован (см. раздел 6.1.5). Системная информация о переменных доступна в этих таблицах Performance Schema:
global_variables
: Глобальные системные переменные.
Приложение, которое хочет только глобальные значения, должно
использовать эту таблицу.
session_variables
: Системные переменные для текущего сеанса.
Приложение, которое хочет все системные значения переменной для собственного
сеанса, должно использовать эту таблицу. Это включает переменные сеанса для
своего сеанса, так же как значения глобальных переменных, у которых нет
никакой сеансовой копии.
variables_by_thread
: Системные переменные сеанса для каждого
активного сеанса. Приложение, которое хочет знать значения переменной сеанса
для определенных сеансов, должно использовать эту таблицу. Это включает
только переменные сеанса, идентифицированные ID потока.variables_info
:
Показывает для каждой системной переменной источник, из которого это было
последний раз установлено, и диапазон значений. См.
раздел 23.9.13.1.Таблицы переменной сеанса
(
session_variables
,
variables_by_thread
) содержат информацию только для активных
сеансов, не законченных сеансов.
TRUNCATE TABLE
не
допускается для системных таблиц переменных Performance Schema.
У
global_variables
и
session_variables
есть эти столбцы:
VARIABLE_NAME
Системное имя переменной.
VARIABLE_VALUE
Системное значение переменной. Для
global_variables
этот столбец содержит глобальное значение. Для
session_variables
этот столбец содержит значение переменной
для текущего сеанса.
У
global_variables
и
session_variables
есть индексы:
Первичный ключ на (VARIABLE_NAME
).
У
variables_by_thread
есть эти столбцы:
THREAD_ID
Идентификатор потока сеанса, в котором определена системная переменная.
VARIABLE_NAME
Системное имя переменной.
VARIABLE_VALUE
Значение переменной сеанса для сеанса, названного в столбце
THREAD_ID
.
У
variables_by_thread
есть эти индексы:
Первичный ключ на (THREAD_ID
,
VARIABLE_NAME
).
variables_by_thread
содержит системную информацию о переменных
только о потоках переднего плана. Если не все потоки будут инструментованы
Performance Schema, эта таблица пропустит некоторые строки. В этом случае
переменная состояния
Performance_schema_thread_instances_lost
будет больше, чем ноль.
variables_info
для каждой системной переменной показывает источник, из которого это было
последний раз установлено, и его диапазон значений.
У variables_info
есть эти столбцы:
VARIABLE_NAME
Имя переменной.
VARIABLE_SOURCE
Источник, из которого была последний раз установлена переменная:
COMMAND_LINE
Переменная была установлена из командной строки.
COMPILED
У переменной есть значение по умолчанию. COMPILED
это
значение, используемое для переменных, не заданных любым другим путем.
DYNAMIC
Переменная была установлена во время выполнения. Это включает задание
переменных в пределах файлов, определенных, используя опцию
--init-file
.
EXPLICIT
Переменная была установлена из файла опции, названного в опции
--defaults-file
.
EXTRA
Переменная была установлена из файла опции, названного в опции
--defaults-extra-file
.
GLOBAL
Переменная была установлена из глобального файла опции. Это включает файлы
опции, не покрытые EXPLICIT
, EXTRA
,
LOGIN
, PERSISTED
,
SERVER
или USER
.
LOGIN
Переменная была установлена из определенного для пользователя файла входа
в систему (~/.mylogin.cnf
).
PERSISTED
Переменная была установлена из определенного для сервера файла опций
mysqld-auto.cnf
. Ни у какой строки нет этого значения, если
сервер был запущен с выключенной
persisted_globals_load
.
SERVER
Переменная была установлена из определенного для сервера файла опций
. Для деталей см.
раздел 5.2.6.$MYSQL_HOME
/my.cnf
USER
Переменная была установлена из определенного для пользователя файла опций
~/.my.cnf
.
VARIABLE_PATH
Если переменная была установлена из файла опции,
VARIABLE_PATH
путь к этому файлу. Иначе значение пустая строка.
MIN_VALUE
, MAX_VALUE
Минимальные и максимальные разрешенные значения для переменной. Оба 0 для переменных, у которых нет таких значений (то есть, переменные, которые не являются числовыми).
TRUNCATE TABLE
не
позволен для variables_info
.
Если переменная с VARIABLE_SOURCE
, кроме DYNAMIC
установлена во время выполнения, VARIABLE_SOURCE
становится
DYNAMIC
, а VARIABLE_PATH
пустой строкой.
Системная переменная, у которой есть только значение сеанса (такая как
debug_sync
)
не может быть установлена при запуске. Для системных переменных только для
сеанса VARIABLE_SOURCE
может быть только
COMPILED
или DYNAMIC
.
Если у системной переменной есть неожиданное
VARIABLE_SOURCE
,
рассмотрите свой метод запуска сервера. Например,
mysqld_safe
читает файлы опции и передает определенные опции, которые он находит там
как часть командной строки, которую он использует, чтобы запустить
mysqld.
Следовательно, некоторые системные переменные, которые Вы устанавливаете в
файлах опции, могли бы отобразиться в
variables_info
как
COMMAND_LINE
вместо GLOBAL
или SERVER
.
Некоторые типовые запросы, которые используют
variables_info
:
Показать переменные из командной строки:
mysql> SELECT VARIABLE_NAME FROM variables_info WHERE VARIABLE_SOURCE = 'COMMAND_LINE' ORDER BY VARIABLE_NAME; +---------------+ | VARIABLE_NAME | +---------------+ | basedir | | datadir | | log_error | | pid_file | | plugin_dir | | port | +---------------+
mysql> SELECT VARIABLE_NAME FROM variables_info WHERE VARIABLE_SOURCE = 'PERSISTED' ORDER BY VARIABLE_NAME; +--------------------------+ | VARIABLE_NAME | +--------------------------+ | event_scheduler | | expire_logs_days | | max_connections | | validate_password_policy | +--------------------------+
variables_info
с
global_variables
, чтобы вывести на экран текущие значения
сохраненных переменных, вместе с их диапазоном значений:
mysql> SELECT VI.VARIABLE_NAME, GV.VARIABLE_VALUE, VI.MIN_VALUE,VI.MAX_VALUE FROM variables_info AS VI INNER JOIN global_variables AS GV USING(VARIABLE_NAME) WHERE VI.VARIABLE_SOURCE = 'PERSISTED' ORDER BY VARIABLE_NAME; +--------------------------+----------------+-----------+-----------+ | VARIABLE_NAME | VARIABLE_VALUE | MIN_VALUE | MAX_VALUE | +--------------------------+----------------+-----------+-----------+ | event_scheduler | ON | 0 | 0 | | expire_logs_days | 7 | 0 | 99 | | max_connections | 200 | 1 | 100000 | | validate_password_policy | STRONG | 0 | 0 | +--------------------------+----------------+-----------+-----------+
Значение переменной
show_compatibility_56
затрагивает информацию, доступную из
таблиц, описанных здесь. Для деталей см. описание этой переменной в
разделе 6.1.5.
Сервер MySQL поддерживает много переменных состояния, которые предоставляют информацию о его работе (см. раздел 6.1.7). Информация о переменной состояния доступна в этих таблицах Performance Schema:
global_status
: Глобальные переменные состояния. Приложение,
которое хочет только глобальные значения, должно использовать эту таблицу.
session_status
: Переменные состояния для текущего сеанса.
Приложение, которое хочет все значения переменной состояния для собственного
сеанса, должно использовать эту таблицу. Это включает переменные сеанса для
своего сеанса, так же как значения глобальных переменных, у которых нет
никакой сеансовой копии.
status_by_thread
: Переменные состояния сеанса для каждого
активного сеанса. Приложение, которое хочет знать значения переменной сеанса
для определенных сеансов, должно использовать эту таблицу. Это включает
только переменные сеанса, идентифицированные ID потока.Есть также сводные таблицы, которые предоставляют информацию о переменных состояния, связанные учетной записью, именем хоста и именем пользователя. См. раздел 23.9.15.11.
Таблицы переменной сеанса
(
session_status
,
status_by_thread
) содержат информацию только для активных, а
не законченных сеансов.
Performance Schema собирает статистические данные для глобальных
переменных состояния только для потоков для которых значение
INSTRUMENTED
YES
в
threads
.
Статистические данные для переменных состояния сеанса всегда собираются,
независимо от значения INSTRUMENTED
.
Performance Schema не собирает статистические данные для
переменных состояния Com_
в
таблицах переменных состояния. Чтобы получить глобальное и сессионное
количество выполнения запросов за сеанс, используйте
xxx
events_statements_summary_global_by_event_name
и
events_statements_summary_by_thread_by_event_name
, соответственно. Например:
SELECT EVENT_NAME, COUNT_STAR FROM events_statements_summary_global_by_event_name WHERE EVENT_NAME LIKE 'statement/sql/%';
У
global_status
и
session_status
есть эти столбцы:
VARIABLE_NAME
Имя переменной состояния.
VARIABLE_VALUE
Значение переменной состояния. Для
global_status
этот столбец содержит глобальное значение. Для
session_status
этот столбец содержит значение для текущего сеанса.
У
global_status
и
session_status
есть индексы:
Первичный ключ на (VARIABLE_NAME
).
status_by_thread
содержит состояние каждого активного потока. У
нее есть эти столбцы:
THREAD_ID
Идентификатор потока сеанса, в котором определена переменная состояния.
VARIABLE_NAME
Имя переменной состояния.
VARIABLE_VALUE
Значение переменной сеанса для сеанса,
названного в столбце THREAD_ID
.
У
status_by_thread
есть эти индексы:
Первичный ключ на (THREAD_ID
,
VARIABLE_NAME
).
status_by_thread
содержит информацию о переменной состояния только
о потоках переднего плана. Если переменная
performance_schema_max_thread_instances
не автомасштабируется
(установлена в -1), и максимальное разрешенное число инструментованных
объектов потока не больше, чем число фоновых потоков, таблица будет пуста.
Performance Schema поддерживает
TRUNCATE TABLE
для таблиц переменных состояния следующим образом:
global_status
: Сбрасывает потоки, учетные записи, узлы и
пользователей. Сбрасывает глобальные переменные состояния кроме тех, которые
никогда не сбрасывает сервер.
session_status
: Не поддерживается.
status_by_thread
: Состояние совокупностей для всех потоков к
глобальному состоянию и состоянию учетной записи, затем сбрасывает состояние
потока. Если статистические данные учетной записи не собраны, состояние
сеанса добавлено к состояниям хоста и пользователя, если они собраны.
Учетная запись, узел и пользовательская статистика не собраны, если
переменные
performance_schema_accounts_size
,
performance_schema_hosts_size
и
performance_schema_users_size
, соответственно, установлены в 0.
FLUSH STATUS
добавляет состояние сеанса из всех активных сеансов в глобальные переменные
состояния, сбрасывает состояние всех активных сеансов и сбрасывает значения
состояния учетной записи, узла и пользователя от разъединенных сеансов.
Сводные таблицы предоставляют соединенную информацию для законченных событий в течение долгого времени. Таблицы в этой группе суммируют данные событий по-разному.
Резюме событий ожидания:
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
:
События ожидания, полученные на имя события.Резюме этапа:
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_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
:
События запросов на имя события.
prepared_statements_instances
:
Готовые случаи запроса и статистика.Операционные резюме:
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
:
Операционные события на имя события.Резюме ожидания объекта:
objects_summary_global_by_type
: Резюме объекта.
Резюме ввода/вывода файла:
file_summary_by_event_name
: События файла на имя события.
file_summary_by_instance
: События файла на случай файла.Табличный ввод / вывод и ожидание блокировки:
table_io_waits_summary_by_index_usage
:
Табличный ввод/вывод на индекс.
table_io_waits_summary_by_table
:
Табличный ввод/вывод на таблицу.
table_lock_waits_summary_by_table
:
Табличная блокировка на таблицу.Резюме сокета:
socket_summary_by_instance
:
Ожидание и ввод/вывод сокета на случай.
socket_summary_by_event_name
:
Ожидание и ввод/вывод сокета на имя события.Резюме памяти:
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
:
Операции памяти на глобально за имя события.Резюме ошибок:
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
:
Ошибки на код ошибки.Резюме переменных состояния:
status_by_account
:
Переменные состояния, связанные с учетной записью.
status_by_host
:
Переменные состояния, связанные с именем хоста.status_by_user
:
Переменные состояния, связанные с именем пользователя.У каждой сводной таблицы есть группирующиеся столбцы, которые определяют, как сгруппировать данные, которые будут соединены, и сводные столбцы, которые содержат соединенные значения. Таблицы, которые суммируют события похожими способами, имеют подобные наборы сводных столбцов и отличаются только по группирующимся столбцам, используемым, чтобы определить, как соединены события.
Сводные таблицы могут быть усечены с
TRUNCATE TABLE
.
Вообще, эффект состоит в том, чтобы сбросить сводные столбцы к 0 или
NULL
, а не удалить строки. Это позволяет очистить
собранные значения. Это могло бы быть полезно, например, после того, как Вы
произвели изменение конфигурации во время выполнения. Исключения к этому
поведению усечения отмечены в отдельных разделах сводной таблицы.
Performance Schema поддерживает таблицы для того, чтобы собрать актуальные и недавние события. раздел 23.9.4 описывает события, на которых базируются резюме.
Пример информации о резюме событий:
mysql> SELECT * FROM events_waits_summary_global_by_event_name\G ... *************************** 6. row *************************** EVENT_NAME: wait/synch/mutex/sql/BINARY_LOG::LOCK_index COUNT_STAR: 8 SUM_TIMER_WAIT: 2119302 MIN_TIMER_WAIT: 196092 AVG_TIMER_WAIT: 264912 MAX_TIMER_WAIT: 569421 ... *************************** 9. row *************************** EVENT_NAME: wait/synch/mutex/sql/hash_filo::lock COUNT_STAR: 69 SUM_TIMER_WAIT: 16848828 MIN_TIMER_WAIT: 0 AVG_TIMER_WAIT: 244185 MAX_TIMER_WAIT: 735345 ...
У сводной таблицы событий есть один или более группирующихся столбцов,
чтобы указать как табличные события объединяются. Имена событий обращаются к
названиям инструментов событий в
setup_instruments
.
events_waits_summary_by_account_by_event_name
имеет столбцы
EVENT_NAME
, USER
и HOST
.
Каждая строка суммирует события для сделанного отчета (комбинация
пользователя и узла) и имя событий.
events_waits_summary_by_host_by_event_name
имеет столбцы
EVENT_NAME
и HOST
.
Каждая строка суммирует события для данного узла и имени событий.
events_waits_summary_by_instance
имеет столбцы EVENT_NAME
и OBJECT_INSTANCE_BEGIN
.
Каждая строка суммирует события для данного имени событий и объекта. Если
инструмент используется, чтобы создать многократные случаи, у каждого случая
есть уникальное значение OBJECT_INSTANCE_BEGIN
и он получен в итоге отдельно в этой таблице.
events_waits_summary_by_thread_by_event_name
имеет столбцы THREAD_ID
и EVENT_NAME
.
Каждая строка суммирует события для данного потока и имени событий.
events_waits_summary_by_user_by_event_name
имеет столбцы EVENT_NAME
и USER
. Каждая строка
суммирует события для данного пользователя и имени событий.
events_waits_summary_global_by_event_name
имеет столбец
EVENT_NAME
. Каждая строка суммирует события для данного имени
событий. Инструмент мог бы использоваться, чтобы создать многократные случаи
инструментованного объекта. Например, если есть инструмент для mutex, который
создается для каждого соединения, есть так много случаев, сколько есть
соединений. Сводная строка для инструмента подводит итог по
всем этим случаям.У сводной таблицы событий есть эти сводные столбцы, содержащие соединенные значения:
COUNT_STAR
Число полученных в итоге событий. Это значение включает все события.
SUM_TIMER_WAIT
Общее количество времени ожидания полученных в итоге рассчитанных событий.
Это значение вычислено только для рассчитанных событий, потому что у
нерассчитанных событий время ожидания NULL
. The
То же самое истина для других значений
.xxx
_TIMER_WAIT
MIN_TIMER_WAIT
Минимум времени ожидания полученных в итоге рассчитанных событий.
AVG_TIMER_WAIT
Среднее время ожидания полученных в итоге рассчитанных событий.
MAX_TIMER_WAIT
Максимум времени ожидания полученных в итоге рассчитанных событий.
Сводные таблицы событий имеют индексы:
events_waits_summary_by_account_by_event_name
:
Первичный ключ на (USER
,
HOST
, EVENT_NAME
).
events_waits_summary_by_host_by_event_name
:
Первичный ключ на (HOST
,
EVENT_NAME
).
events_waits_summary_by_instance
:
Первичный ключ на (OBJECT_INSTANCE_BEGIN
).
EVENT_NAME
).
events_waits_summary_by_thread_by_event_name
:
Первичный ключ на (THREAD_ID
,
EVENT_NAME
).
events_waits_summary_by_user_by_event_name
:
Первичный ключ на (USER
,
EVENT_NAME
).
events_waits_summary_global_by_event_name
:
Первичный ключ на (EVENT_NAME
).
TRUNCATE TABLE
позволен
на сводных таблицах. Это имеет эффекты:
Для сводных таблиц, не соединенных с учетной записью, узлом или пользователем, усечение сбрасывает сводные столбцы к нолю вместо того, чтобы удалить строки.
Кроме того, каждая сводная таблица, которая соединена с учетной записью,
узлом, пользователем или потоком является неявно усеченной усечением таблицы
соединения, от которой зависит или усечением
events_waits_summary_global_by_event_name
.
Performance Schema поддерживает таблицы для того, чтобы собрать текущие и недавние события этапа. Раздел 23.9.5 описывает события, на которых базируются резюме этапа.
Информация о резюме этапа событий в качестве примера:
mysql> SELECT * FROM events_stages_summary_global_by_event_name\G ... *************************** 5. row *************************** EVENT_NAME: stage/sql/checking permissions COUNT_STAR: 57 SUM_TIMER_WAIT: 26501888880 MIN_TIMER_WAIT: 7317456 AVG_TIMER_WAIT: 464945295 MAX_TIMER_WAIT: 12858936792 ... *************************** 9. row *************************** EVENT_NAME: stage/sql/closing tables COUNT_STAR: 37 SUM_TIMER_WAIT: 662606568 MIN_TIMER_WAIT: 1593864 AVG_TIMER_WAIT: 17907891 MAX_TIMER_WAIT: 437977248 ...
У каждой сводной таблицы этапа есть один или более группирующихся
столбцов, чтобы указать как табличные события объединяются.
Имена событий обращаются к названиям инструментов событий в
setup_instruments
.
events_stages_summary_by_account_by_event_name
имеет столбцы
EVENT_NAME
, USER
и HOST
.
Каждая строка суммирует события для сделанного отчета (комбинация
пользователя и узла) и имени события.
events_stages_summary_by_host_by_event_name
имеет столбцы EVENT_NAME
и HOST
.
Каждая строка суммирует события для данного узла и имени событий.
events_stages_summary_by_thread_by_event_name
имеет столбцы THREAD_ID
и EVENT_NAME
.
Каждая строка суммирует события для данного потока и имени событий.
events_stages_summary_by_user_by_event_name
имеет столбцы EVENT_NAME
и USER
. Каждая строка
суммирует события для данного пользователя и имени событий.
events_stages_summary_global_by_event_name
имеет столбец EVENT_NAME
.
Каждая строка суммирует события для данного имени события.У каждой сводной таблицы этапа есть эти сводные столбцы,
содержащие соединенные значения: COUNT_STAR
,
SUM_TIMER_WAIT
, MIN_TIMER_WAIT
,
AVG_TIMER_WAIT
и MAX_TIMER_WAIT
.
Эти столбцы походят на столбцы с теми же именами в сводных таблицах событий
ожидания (см. раздел 23.9.15.1),
за исключением того, что события совокупности сводных таблиц этапа из
events_stages_current
вместо
events_waits_current
.
Сводные таблицы этапа имеют индексы:
events_stages_summary_by_account_by_event_name
:
Первичный ключ на (USER
,
HOST
, EVENT_NAME
).
events_stages_summary_by_host_by_event_name
:
Первичный ключ на (HOST
, EVENT_NAME
).
events_stages_summary_by_thread_by_event_name
:
Первичный ключ на (THREAD_ID
,
EVENT_NAME
).
events_stages_summary_by_user_by_event_name
:
Первичный ключ на (USER
,
EVENT_NAME
).
events_stages_summary_global_by_event_name
:
Первичный ключ на (EVENT_NAME
).
TRUNCATE TABLE
позволен
на сводных таблицах этапа. Это имеет эффекты:
Для сводных таблиц, не соединенных с учетной записью, узлом или пользователем, усечение сбрасывает сводные столбцы к нолю вместо того, чтобы удалить строки.
Кроме того, каждая сводная таблица этапа, которая соединена с учетной
записью, узлом, пользователем или потоком, является неявно усеченной
усечением таблицы, от которой это зависит, или усечением
events_stages_summary_global_by_event_name
.
Performance Schema поддерживает таблицы для того, чтобы собрать текущие и недавние события запросов. Раздел 23.9.6 описывает события, на которых базируются резюме запросов.
Информация о резюме запросов событий в качестве примера:
mysql> SELECT * FROM events_statements_summary_global_by_event_name\G *************************** 1. row *************************** EVENT_NAME: statement/sql/select COUNT_STAR: 25 SUM_TIMER_WAIT: 1535983999000 MIN_TIMER_WAIT: 209823000 AVG_TIMER_WAIT: 61439359000 MAX_TIMER_WAIT: 1363397650000 SUM_LOCK_TIME: 20186000000 SUM_ERRORS: 0 SUM_WARNINGS: 0 SUM_ROWS_AFFECTED: 0 SUM_ROWS_SENT: 388 SUM_ROWS_EXAMINED: 370 SUM_CREATED_TMP_DISK_TABLES: 0 SUM_CREATED_TMP_TABLES: 0 SUM_SELECT_FULL_JOIN: 0 SUM_SELECT_FULL_RANGE_JOIN: 0 SUM_SELECT_RANGE: 0 SUM_SELECT_RANGE_CHECK: 0 SUM_SELECT_SCAN: 6 SUM_SORT_MERGE_PASSES: 0 SUM_SORT_RANGE: 0 SUM_SORT_ROWS: 0 SUM_SORT_SCAN: 0 SUM_NO_INDEX_USED: 6 SUM_NO_GOOD_INDEX_USED: 0 ...
У каждой сводной таблицы запросы есть один или более группирующихся
столбцов, чтобы указать как табличные события объединяются. Имена событий
обращаются к названиям инструментов событий в
setup_instruments
.
events_statements_summary_by_account_by_event_name
имеет столбцы EVENT_NAME
, USER
и HOST
.
Каждая строка суммирует события для сделанного отчета (комбинация
пользователя и узла) и имя событий.
events_statements_summary_by_digest
имеет столбцы
SCHEMA_NAME
и DIGEST
.
Каждая строка суммирует события для данных значений схемы/обзора.
DIGEST_TEXT
содержит соответствующий нормализованный текст
обзора запроса, но не является ни группировкой, ни сводным столбцом.
Максимальное количество строк в таблице задано при запуске сервера. Чтобы
установить этот максимум явно, установите системнуюая переменную
performance_schema_digests_size
при запуске сервера.
events_statements_summary_by_host_by_event_name
имеет столбцы
EVENT_NAME
и HOST
.
Каждая строка суммирует события для данного узла и имени событий.
events_statements_summary_by_program
имеет столбцы
OBJECT_TYPE
, OBJECT_SCHEMA
и
OBJECT_NAME
. Каждая строка суммирует события для данной
сохраненной программы (хранимая процедура или функция, триггер или событие).
events_statements_summary_by_thread_by_event_name
имеет столбцы
THREAD_ID
и EVENT_NAME
.
Каждая строка суммирует события для данного потока и имени событий.
events_statements_summary_by_user_by_event_name
имеет столбцы
EVENT_NAME
и USER
. Каждая строка суммирует события
для данного пользователя и имени событий.
events_statements_summary_global_by_event_name
имеет столбец EVENT_NAME
. Каждая строка суммирует события для
данного имени события.
prepared_statements_instances
имеет столбец OBJECT_INSTANCE_BEGIN
. Каждая строка суммирует
события для данного подготовленного запроса.У каждой сводной таблицы запросов есть эти сводные столбцы, содержащие соединенные значения (с исключениями, как отмечено):
COUNT_STAR
, SUM_TIMER_WAIT
,
MIN_TIMER_WAIT
, AVG_TIMER_WAIT
,
MAX_TIMER_WAIT
Эти столбцы походят на столбцы с теми же самыми именами в
сводных таблицах событий (см.
раздел 23.9.15.1), за исключением того, что события сводных таблиц
запросов собраны из
events_statements_current
вместо
events_waits_current
.
У
prepared_statements_instances
нет этих столбцов.
SUM_xxx
Совокупность соответствующих столбцов xxx
в
events_statements_current
. Например, столбцы
SUM_LOCK_TIME
и SUM_ERRORS
в сводных таблицах запросов это совокупности столбцов
LOCK_TIME
и ERRORS
в
events_statements_current
.
У
events_statements_summary_by_digest
есть эти дополнительные сводные столбцы:
FIRST_SEEN_TIMESTAMP
,
LAST_SEEN_TIMESTAMP
Времена, в которые запрос с данным значением обзора был замечен в первый и последний раз.
У
events_statements_summary_by_program
есть эти дополнительные сводные столбцы:
COUNT_STATEMENTS
, SUM_STATEMENTS_WAIT
,
MIN_STATEMENTS_WAIT
, AVG_STATEMENTS_WAIT
,
MAX_STATEMENTS_WAIT
Статистика о вложенных запросах во время выполнения сохраненной программы.
У
prepared_statements_instances
есть эти дополнительные сводные столбцы:
COUNT_EXECUTE
, SUM_TIMER_EXECUTE
,
MIN_TIMER_EXECUTE
, AVG_TIMER_EXECUTE
,
MAX_TIMER_EXECUTE
Соединенная статистика для выполнения готового запроса.
Сводные таблицы запросы имеют индексы:
events_transactions_summary_by_account_by_event_name
:
Первичный ключ на (USER
,
HOST
, EVENT_NAME
).
events_statements_summary_by_digest
:
Первичный ключ на (SCHEMA_NAME
,
DIGEST
).
events_transactions_summary_by_host_by_event_name
:
Первичный ключ на (HOST
,
EVENT_NAME
).
events_statements_summary_by_program
:
Первичный ключ на (OBJECT_TYPE
,
OBJECT_SCHEMA
, OBJECT_NAME
).
events_statements_summary_by_thread_by_event_name
:
Первичный ключ на (THREAD_ID
,
EVENT_NAME
).
events_transactions_summary_by_user_by_event_name
:
Первичный ключ на (USER
,
EVENT_NAME
).
У
events_statements_summary_global_by_event_name
есть эти индексы:
Первичный ключ на (EVENT_NAME
).
TRUNCATE TABLE
позволен
для сводных таблиц запросов. Это имеет эффекты:
Для
events_statements_summary_by_digest
это удаляет строки.
Кроме того, каждая сводная таблица запросов, которая соединена с учетной
записью, узлом, пользователем или потоком, является неявно усеченной
усечением таблицы соединения, от которой зависит, или усечением
events_statements_summary_global_by_event_name
.
Если потребитель включен statement_digest
, агрегация в
events_statements_summary_by_digest
происходит следующим образом, когда запрос завершается. Агрегация основана на
значении DIGEST
, вычисленном для запроса.
Если строка
events_statements_summary_by_digest
уже существует со значением
обзора для запроса, который только что завершился, статистические данные для
запроса присоединены к этой строке. Столбец LAST_SEEN
обновлен к текущему времени.
FIRST_SEEN
и LAST_SEEN
инициализированы с текущим временем.DIGEST
= NULL
,
который создается в случае необходимости. Если строка создается, столбцы
FIRST_SEEN
и LAST_SEEN
инициализированы с текущим временем. Иначе LAST_SEEN
обновлен с текущим временем.Строка с DIGEST
= NULL
поддержана, потому что у
таблиц Performance Schema есть максимальный размер из-за ограничений памяти.
Строка DIGEST
= NULL
разрешает обзоры, которые не
соответствуют другим строкам, которые будут посчитаны, даже если сводная
таблица полна. Эта строка помогает Вам оценить, является ли
резюме обзора представительным:
Строка DIGEST
= NULL
, у которой есть
значение COUNT_STAR
, которое представляет 5% всех обзоров,
показывает, что сводная таблица обзора является очень представительной:
другие строки покрывают 95% замеченных запросов.
DIGEST
= NULL
, у которой есть
значение COUNT_STAR
, которое представляет 50% всех обзоров,
показывает, что сводная таблица обзора не является очень представительной:
другие строки покрывают только половину замеченных запросов. Наиболее
вероятно DBA должен увеличить максимальный табличный размер так, чтобы больше
строк включилось, а строка DIGEST
= NULL
была бы посчитана, используя более определенные строки вместо этого.
Чтобы сделать это, установите системную переменную
performance_schema_digests_size
к большему значению при запуске
сервера. Размер значения по умолчанию 200.Для типов сохраненных программ, для которых инструментовка включена в
setup_objects
,
events_statements_summary_by_program
поддерживает статистику для сохраненных программ следующим образом:
Строка добавлена для объекта, когда он сначала используется в сервере.
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
.
events_transactions_summary_by_account_by_event_name
имеет столбцы
USER
, HOST
и EVENT_NAME
.
Каждая строка суммирует события для сделанного отчета (комбинация
пользователя и узла) и имя событий.
events_transactions_summary_by_host_by_event_name
имеет столбцы
HOST
и EVENT_NAME
.
Каждая строка суммирует события для данного узла и имени событий.
events_transactions_summary_by_thread_by_event_name
имеет столбцы
THREAD_ID
и EVENT_NAME
.
Каждая строка суммирует события для данного потока и имени событий.
events_transactions_summary_by_user_by_event_name
имеет столбцы
USER
и EVENT_NAME
. Каждая строка суммирует события
для данного пользователя и имени событий.
events_transactions_summary_global_by_event_name
имеет столбец
EVENT_NAME
. Каждая строка суммирует события для
данного имени событий.У каждой операционной сводной таблицы есть эти сводные столбцы, содержащие соединенные значения:
COUNT_STAR
, SUM_TIMER_WAIT
,
MIN_TIMER_WAIT
, AVG_TIMER_WAIT
,
MAX_TIMER_WAIT
Эти столбцы походят на столбцы с теми же самыми именами в
сводных таблицах событий ожидания за исключением того, что операционные
события сводных таблиц из
events_transactions_current
вместо
events_waits_current
. Эти столбцы суммируют транзакции только для
чтения и чтения-записи.
COUNT_READ_WRITE
, SUM_TIMER_READ_WRITE
,
MIN_TIMER_READ_WRITE
, AVG_TIMER_READ_WRITE
,
MAX_TIMER_READ_WRITE
Они подобны COUNT_STAR
и
, но подводят итог
только транзакций чтения-записи.xxx
_TIMER_WAIT
COUNT_READ_ONLY
, SUM_TIMER_READ_ONLY
,
MIN_TIMER_READ_ONLY
, AVG_TIMER_READ_ONLY
,
MAX_TIMER_READ_ONLY
Они подобны COUNT_STAR
и
, но подводят итог
только транзакций чтения.xxx
_TIMER_WAIT
Операционные сводные таблицы имеют индексы:
events_transactions_summary_by_account_by_event_name
:
Первичный ключ на (USER
,
HOST
, EVENT_NAME
).
events_transactions_summary_by_host_by_event_name
:
Первичный ключ на (HOST
,
EVENT_NAME
).
events_transactions_summary_by_thread_by_event_name
:
Первичный ключ на (THREAD_ID
,
EVENT_NAME
).
events_transactions_summary_by_user_by_event_name
:
Первичный ключ на (USER
,
EVENT_NAME
).
events_transactions_summary_global_by_event_name
:
Первичный ключ на (EVENT_NAME
).
TRUNCATE TABLE
позволен
для операционных сводных таблиц. Это имеет эффекты:
Для сводных таблиц, не соединенных с учетной записью, узлом или пользователем, усечение сбрасывает сводные столбцы к нолю вместо того, чтобы удалить строки.
Операционный сбор событий происходит без отношения с уровнем изоляции, режимом доступа или режимом autocommit.
Транзакции чтения-записи вообще требуют больше ресурсов, чем транзакции только для чтения, поэтому операционные сводные таблицы включают отдельные совокупные столбцы для чтения-записи и транзакции только для чтения.
Требования ресурса могут также меняться в зависимости от операционного уровня изоляции. Однако, предполагая, что только один уровень изоляции использовался бы на сервере, агрегирование уровнем изоляции не обеспечено.
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_
. См.
раздел 23.9.15.1.xxx
У
objects_summary_global_by_type
есть эти индексы:
Первичный ключ на (OBJECT_TYPE
,
OBJECT_SCHEMA
, OBJECT_NAME
).
TRUNCATE TABLE
позволен
для сводной таблицы объекта. Это сбрасывает сводные столбцы к нолю вместо
того, чтобы удалить строки.
Performance Schema поддерживает сводные таблицы ввода/вывода файла.
Информация о резюме событий ввода/вывода файла в качестве примера:
mysql> SELECT * FROM file_summary_by_event_name\G ... *************************** 2. row *************************** EVENT_NAME: wait/io/file/sql/binlog COUNT_STAR: 31 SUM_TIMER_WAIT: 8243784888 MIN_TIMER_WAIT: 0 AVG_TIMER_WAIT: 265928484 MAX_TIMER_WAIT: 6490658832 ... mysql> SELECT * FROM file_summary_by_instance\G ... *************************** 2. row *************************** FILE_NAME: /var/mysql/share/english/errmsg.sys EVENT_NAME: wait/io/file/sql/ERRMSG EVENT_NAME: wait/io/file/sql/ERRMSG OBJECT_INSTANCE_BEGIN: 4686193384 COUNT_STAR: 5 SUM_TIMER_WAIT: 13990154448 MIN_TIMER_WAIT: 26349624 AVG_TIMER_WAIT: 2798030607 MAX_TIMER_WAIT: 8150662536 ...
У каждой сводной таблицы ввода/вывода файла есть один или более
группирующихся столбцов, чтобы указать как табличные события объединяются.
Имена событий обращаются к названиям инструментов событий в
setup_instruments
.
file_summary_by_event_name
имеет столбец
EVENT_NAME
. Каждая строка суммирует события для
данного имени событий.
file_summary_by_instance
имеет столбцы FILE_NAME
, EVENT_NAME
и
OBJECT_INSTANCE_BEGIN
. Каждая строка суммирует события для
данного файла и имени событий.У каждой сводной таблицы ввода/вывода файла есть следующие сводные столбцы, содержащие соединенные значения. Некоторые столбцы являются более общими и имеют значения, которые являются тем же самым, как сумма более узконаправленных столбцов. Таким образом, данные в более высоких уровнях доступны непосредственно без потребности в определяемых пользователем представлениях, которые суммируют столбцы низшего уровня.
COUNT_STAR
, SUM_TIMER_WAIT
,
MIN_TIMER_WAIT
, AVG_TIMER_WAIT
,
MAX_TIMER_WAIT
.
Эти столбцы агрегируют все операции ввода/вывода.
COUNT_READ
, SUM_TIMER_READ
,
MIN_TIMER_READ
, AVG_TIMER_READ
,
MAX_TIMER_READ
, SUM_NUMBER_OF_BYTES_READ
.
Эти столбцы агрегируют все операции чтения, включая
FGETS
, FGETC
,
FREAD
и READ
.
COUNT_WRITE
, SUM_TIMER_WRITE
,
MIN_TIMER_WRITE
, AVG_TIMER_WRITE
,
MAX_TIMER_WRITE
, SUM_NUMBER_OF_BYTES_WRITE
Эти столбцы агрегируют все операции записи, включая
FPUTS
, FPUTC
,
FPRINTF
, VFPRINTF
,
FWRITE
и PWRITE
.
COUNT_MISC
, SUM_TIMER_MISC
,
MIN_TIMER_MISC
, AVG_TIMER_MISC
,
MAX_TIMER_MISC
Эти столбцы агрегируют все другие операции ввода/вывода, включая
CREATE
, DELETE
, OPEN
,
CLOSE
, STREAM_OPEN
, STREAM_CLOSE
,
SEEK
, TELL
, FLUSH
, STAT
,
FSTAT
, CHSIZE
, RENAME
и
SYNC
. Нет никаких счетчиков байтов для этих операций.
Сводные таблицы ввода/вывода файла имеют индексы:
Первичный ключ на (EVENT_NAME
).
Первичный ключ на (OBJECT_INSTANCE_BEGIN
).
FILE_NAME
).EVENT_NAME
).TRUNCATE TABLE
позволен
для сводных таблиц ввода/вывода файла. Это сбрасывает сводные столбцы к
нолю вместо того, чтобы удалить строки.
Сервер MySQL использует несколько методов, чтобы избежать операций ввода/вывода, кэшируя информацию, считанную из файлов, таким образом, возможно, что запросов, которых Вы могли бы ожидать, не будет. Вы можете быть в состоянии гарантировать, что ввод/вывод действительно происходит, сбрасывая кэши или перезапуская сервер, чтобы сбросить его состояние.
Следующие разделы описывают табличный ввод/вывод и ожидание блокировки:
table_io_waits_summary_by_index_usage
:
Табличный ввод/вывод на индекс.
table_io_waits_summary_by_table
:
Табличный ввод/вывод на таблицу.
table_lock_waits_summary_by_table
:
Табличная блокировка на таблицу.
table_io_waits_summary_by_table
собирает весь табличный ввод/вывод, произведенный инструментом
wait/io/table/sql/handler
. Группировка таблицей.
table_io_waits_summary_by_table
имеет эти столбцы группировки, чтобы указать как табличные события
объединены: OBJECT_TYPE
, OBJECT_SCHEMA
и
OBJECT_NAME
. У этих столбцов есть то же самое значение, как в
events_waits_current
. Они идентифицируют таблицу, к которой применяется строка.
table_io_waits_summary_by_table
имеет следующие сводные столбцы, содержащие соединенные значения. Как
обозначено в описаниях столбца, некоторые столбцы являются более общими и
имеют значения, которые являются тем же самым как сумма значений более
детальных столбцов. Например, столбцы, которые собирают все записи, содержат
сумму соответствующих столбцов, которые собирают вставки, обновления и
удаления. Таким образом, данные в более высоких уровнях доступны
непосредственно без потребности в определяемых пользователем представлениях,
которые суммируют столбцы низшего уровня.
COUNT_STAR
, SUM_TIMER_WAIT
,
MIN_TIMER_WAIT
, AVG_TIMER_WAIT
,
MAX_TIMER_WAIT
.
Эти столбцы собирают все операции ввода/вывода. Они то же самое, как сумма
столбцов
и
xxx
_READ
.xxx
_WRITE
COUNT_READ
, SUM_TIMER_READ
,
MIN_TIMER_READ
, AVG_TIMER_READ
,
MAX_TIMER_READ
.
Эти столбцы собирают все операции чтения. Они то же самое, как сумма
столбцов
.xxx
_FETCH
COUNT_WRITE
, SUM_TIMER_WRITE
,
MIN_TIMER_WRITE
, AVG_TIMER_WRITE
,
MAX_TIMER_WRITE
.
Эти столбцы собирают все операции записи. Они то же самое, как сумма
столбцов
,
xxx
_INSERT
и
xxx
_UPDATE
.xxx
_DELETE
COUNT_FETCH
, SUM_TIMER_FETCH
,
MIN_TIMER_FETCH
, AVG_TIMER_FETCH
,
MAX_TIMER_FETCH
Эти столбцы собирают все операции получения.
COUNT_INSERT
, SUM_TIMER_INSERT
,
MIN_TIMER_INSERT
, AVG_TIMER_INSERT
,
MAX_TIMER_INSERT
Эти столбцы собирают все операции вставки.
COUNT_UPDATE
, SUM_TIMER_UPDATE
,
MIN_TIMER_UPDATE
, AVG_TIMER_UPDATE
,
MAX_TIMER_UPDATE
Эти столбцы собирают все операции обновления.
COUNT_DELETE
, SUM_TIMER_DELETE
,
MIN_TIMER_DELETE
, AVG_TIMER_DELETE
,
MAX_TIMER_DELETE
Эти столбцы собирают все операции удаления.
У
table_io_waits_summary_by_table
есть эти индексы:
Индекс Unique на (OBJECT_TYPE
,
OBJECT_SCHEMA
, OBJECT_NAME
).
TRUNCATE TABLE
разрешен
для табличных сводных таблиц ввода/вывода. Это сбрасывает сводные столбцы к
нолю вместо того, чтобы удалить строки. Усечение этой таблицы также усекает
table_io_waits_summary_by_index_usage
.
table_io_waits_summary_by_index_usage
собирает все события
ожидания ввода/вывода индексов как произведено инструментом
wait/io/table/sql/handler
. Группировка по индексу таблицы.
Столбцы
table_io_waits_summary_by_index_usage
почти идентичны
table_io_waits_summary_by_table
. Единственная разница:
дополнительный групповой столбец INDEX_NAME
,
который соответствует названию индекса, который использовался,
когда случай ожидания табличного ввода/вывода был зарегистрирован:
Значение PRIMARY
указывает, что табличный ввод/вывод
использовал первичный индекс.
NULL
указывает, что табличный ввод/вывод
не использовал индекс.INDEX_NAME = NULL
.У
table_io_waits_summary_by_index_usage
есть эти индексы:
Индекс Unique на (OBJECT_TYPE
,
OBJECT_SCHEMA
, OBJECT_NAME
,
INDEX_NAME
)
TRUNCATE TABLE
разрешен для сводных таблиц ввода/вывода. Это сбрасывает сводные столбцы к
нолю вместо того, чтобы удалить строки. Эта таблица является также усеченной
усечением
table_io_waits_summary_by_table
. Операция DDL, которая
изменяет индексную структуру таблицы, может вызвать
сброс статистики индексов.
table_lock_waits_summary_by_table
собирает все события ожидания
табличной блокировки как произведено инструментом
wait/lock/table/sql/handler
. Группировка по таблице.
Эта таблица содержит информацию о внутренних и внешних блокировках:
Внутренняя блокировка соответствует блокировке в уровне SQL. Это в
настоящее время осуществляется вызовом thr_lock()
.
В строках событий эти блокировки отличаются столбцом OPERATION
,
у которого есть одно из этих значений:
read normal read with shared locks read high priority read no insert write allow write write concurrent insert write delayed write low priority write normal
handler::external_lock()
. В строках событий эти блокировки
отличаются столбцом OPERATION
, у которого есть одно
из этих значений:
read external write external
У
table_lock_waits_summary_by_table
есть эти столбцы группировки, чтобы указать как табличные события
объединяются: OBJECT_TYPE
, OBJECT_SCHEMA
и
OBJECT_NAME
. У этих столбцов есть то же самое значение, как в
events_waits_current
. Они идентифицируют таблицу, к которой применяется строка.
table_lock_waits_summary_by_table
имеет следующие сводные столбцы, содержащие соединенные значения. Как
обозначено в описаниях столбца, некоторые столбцы являются более общими и
имеют значения, которые являются тем же самым, как сумма значений более
специальных столбцов. Например, столбцы, которые собирают все блокировки,
хранят сумму столбцов, соответствующих блокировкам чтения и записи.
Таким образом, данные в более высоких уровнях доступны непосредственно без
потребности в определяемых пользователем представлениях, которые суммируют
столбцы низшего уровня.
COUNT_STAR
, SUM_TIMER_WAIT
,
MIN_TIMER_WAIT
, AVG_TIMER_WAIT
,
MAX_TIMER_WAIT
Эти столбцы агрегируют все операции блокировки. Они то же самое, как сумма
соответствующих столбцов
и
xxx
_READ
.xxx
_WRITE
COUNT_READ
, SUM_TIMER_READ
,
MIN_TIMER_READ
, AVG_TIMER_READ
,
MAX_TIMER_READ
Эти столбцы агрегируют все операции блокировки чтения. Они то же самое,
как сумма соответствующих столбцов
, xxx
_READ_NORMAL
, xxx
_READ_WITH_SHARED_LOCKS
и xxx
_READ_HIGH_PRIORITY
.xxx
_READ_NO_INSERT
COUNT_WRITE
, SUM_TIMER_WRITE
,
MIN_TIMER_WRITE
, AVG_TIMER_WRITE
,
MAX_TIMER_WRITE
Эти столбцы агрегируют все операции блокировки записи. Они то же самое,
как сумма соответствующих столбцов
,
xxx
_WRITE_ALLOW_WRITE
,
xxx
_WRITE_CONCURRENT_INSERT
и
xxx
_WRITE_LOW_PRIORITY
.xxx
_WRITE_NORMAL
COUNT_READ_NORMAL
, SUM_TIMER_READ_NORMAL
,
MIN_TIMER_READ_NORMAL
, AVG_TIMER_READ_NORMAL
,
MAX_TIMER_READ_NORMAL
Эти столбцы агрегируют все внутренние блокировки чтения.
COUNT_READ_WITH_SHARED_LOCKS
,
SUM_TIMER_READ_WITH_SHARED_LOCKS
,
MIN_TIMER_READ_WITH_SHARED_LOCKS
,
AVG_TIMER_READ_WITH_SHARED_LOCKS
,
MAX_TIMER_READ_WITH_SHARED_LOCKS
Эти столбцы агрегируют все внутренние блокировки чтения.
COUNT_READ_HIGH_PRIORITY
,
SUM_TIMER_READ_HIGH_PRIORITY
,
MIN_TIMER_READ_HIGH_PRIORITY
,
AVG_TIMER_READ_HIGH_PRIORITY
,
MAX_TIMER_READ_HIGH_PRIORITY
Эти столбцы агрегируют все внутренние блокировки чтения.
COUNT_READ_NO_INSERT
,
SUM_TIMER_READ_NO_INSERT
,
MIN_TIMER_READ_NO_INSERT
,
AVG_TIMER_READ_NO_INSERT
,
MAX_TIMER_READ_NO_INSERT
Эти столбцы агрегируют все внутренние блокировки чтения.
COUNT_READ_EXTERNAL
,
SUM_TIMER_READ_EXTERNAL
,
MIN_TIMER_READ_EXTERNAL
,
AVG_TIMER_READ_EXTERNAL
,
MAX_TIMER_READ_EXTERNAL
Эти столбцы агрегируют все внешние блокировки чтения.
COUNT_WRITE_ALLOW_WRITE
,
SUM_TIMER_WRITE_ALLOW_WRITE
,
MIN_TIMER_WRITE_ALLOW_WRITE
,
AVG_TIMER_WRITE_ALLOW_WRITE
,
MAX_TIMER_WRITE_ALLOW_WRITE
Эти столбцы агрегируют все внутренние блокировки записи.
COUNT_WRITE_CONCURRENT_INSERT
,
SUM_TIMER_WRITE_CONCURRENT_INSERT
,
MIN_TIMER_WRITE_CONCURRENT_INSERT
,
AVG_TIMER_WRITE_CONCURRENT_INSERT
,
MAX_TIMER_WRITE_CONCURRENT_INSERT
Эти столбцы агрегируют все внутренние блокировки записи.
COUNT_WRITE_LOW_PRIORITY
,
SUM_TIMER_WRITE_LOW_PRIORITY
,
MIN_TIMER_WRITE_LOW_PRIORITY
,
AVG_TIMER_WRITE_LOW_PRIORITY
,
MAX_TIMER_WRITE_LOW_PRIORITY
Эти столбцы агрегируют все внутренние блокировки записи.
COUNT_WRITE_NORMAL
, SUM_TIMER_WRITE_NORMAL
,
MIN_TIMER_WRITE_NORMAL
, AVG_TIMER_WRITE_NORMAL
,
MAX_TIMER_WRITE_NORMAL
.
Эти столбцы агрегируют все внутренние блокировки записи.
COUNT_WRITE_EXTERNAL
,
SUM_TIMER_WRITE_EXTERNAL
,
MIN_TIMER_WRITE_EXTERNAL
,
AVG_TIMER_WRITE_EXTERNAL
,
MAX_TIMER_WRITE_EXTERNAL
Эти столбцы агрегируют все внешние блокировки записи.
У
table_lock_waits_summary_by_table
есть эти индексы:
Индекс Unique на (OBJECT_TYPE
,
OBJECT_SCHEMA
, OBJECT_NAME
).
TRUNCATE TABLE
разрешен для сводных таблиц блокировки. Это сбрасывает сводные столбцы к нолю
вместо того, чтобы удалить строки.
Эти сводные таблицы сокета агрегируют информацию таймера и число байт для операций сокета:
socket_summary_by_event_name
:
Собирает статистику с инструментов wait/io/socket/*
для всех операций ввода/вывода сокета на инструмент сокета.
socket_summary_by_instance
:
Собирает статистику с инструментов wait/io/socket/*
для всех операций ввода/вывода сокета случай сокета. Когда соединение
заканчивается, строка в
socket_summary_by_instance
удалена.Сводные таблицы сокета не соединяют ожидания, произведенные событиями
idle
в то время, как сокеты ждут следующего запроса от клиента.
Для агрегирования событий idle
, используйте сводные таблицы
случаев ожидания, см.
раздел 23.9.15.1.
У каждой сводной таблицы сокета есть один или более группирующихся
столбцов, чтобы указать как табличные события объединены.
Имена событий обращаются к названиям инструментов событий в
setup_instruments
.
socket_summary_by_event_name
имеет столбец
EVENT_NAME
. Каждая строка суммирует события для
данного имени событий.
socket_summary_by_instance
имеет столбец
OBJECT_INSTANCE_BEGIN
.
Каждая строка суммирует события для данного объекта.У каждой сводной таблицы сокета есть эти сводные столбцы, содержащие соединенные значения:
COUNT_STAR
, SUM_TIMER_WAIT
,
MIN_TIMER_WAIT
, AVG_TIMER_WAIT
,
MAX_TIMER_WAIT
Эти столбцы агрегируют все операции.
COUNT_READ
, SUM_TIMER_READ
,
MIN_TIMER_READ
, AVG_TIMER_READ
,
MAX_TIMER_READ
, SUM_NUMBER_OF_BYTES_READ
Эти столбцы агрегируют все операции получения
(RECV
, RECVFROM
и RECVMSG
).
COUNT_WRITE
, SUM_TIMER_WRITE
,
MIN_TIMER_WRITE
, AVG_TIMER_WRITE
,
MAX_TIMER_WRITE
, SUM_NUMBER_OF_BYTES_WRITE
Эти столбцы агрегируют все операции передачи
(SEND
, SENDTO
и SENDMSG
).
COUNT_MISC
, SUM_TIMER_MISC
,
MIN_TIMER_MISC
, AVG_TIMER_MISC
,
MAX_TIMER_MISC
Эти столбцы агрегируют все прочие операции, такие как
CONNECT
, LISTEN
,
ACCEPT
, CLOSE
и SHUTDOWN
.
Нет никаких счетчиков байтов для этих операций.
socket_summary_by_instance
также имеет столбец
EVENT_NAME
, который указывает на класс сокета:
client_connection
, server_tcpip_socket
,
server_unix_socket
.
Этот столбец может быть сгруппирован на изоляцию, например, деятельность
клиента, от которого сервер слушает сокеты.
Сводные таблицы сокета имеют индексы:
Первичный ключ на (EVENT_NAME
).
Первичный ключ на (OBJECT_INSTANCE_BEGIN
).
EVENT_NAME
).TRUNCATE TABLE
позволен
на сводных таблицах сокета. За исключением
events_statements_summary_by_digest
это сбрасывает сводные столбцы к нолю вместо того, чтобы удалить строки.
Инструментальное использование памяти Performance Schema и статистика использования памяти детализирована этими факторами:
Тип используемой памяти (различные кэши, внутренние буферы и т.д).
Performance Schema инструментует следующие аспекты использования памяти:
Размеры памяти.
Размеры памяти помогают понять или настроить потребление памяти сервером.
Графы работы помогают понять или настроить полное распределение памяти, который оказывает влияние на работу. Выделение единственного байта один миллион раз не является тем же самым как выделение мегабайта разово, отслеживание количества и размеров может выставить различие.
Метки важны, чтобы обнаружить пики рабочей нагрузки, полную стабильность рабочей нагрузки и возможные утечки памяти.
Сводные таблицы памяти не содержат информацию о синхронизации, потому что события памяти не рассчитаны.
Информация о резюме событий памяти в качестве примера:
mysql> SELECT * FROM memory_summary_global_by_event_name WHERE EVENT_NAME = 'memory/sql/TABLE'\G *************************** 1. row *************************** EVENT_NAME: memory/sql/TABLE COUNT_ALLOC: 1381 COUNT_FREE: 924 SUM_NUMBER_OF_BYTES_ALLOC: 2059873 SUM_NUMBER_OF_BYTES_FREE: 1407432 LOW_COUNT_USED: 0 CURRENT_COUNT_USED: 457 HIGH_COUNT_USED: 461 LOW_NUMBER_OF_BYTES_USED: 0 CURRENT_NUMBER_OF_BYTES_USED: 652441 HIGH_NUMBER_OF_BYTES_USED: 669269
У каждой сводной таблицы памяти есть один или более группирующихся
столбцов, чтобы указать как табличные события объединены. Имена событий
обращаются к названиям инструментов событий в
setup_instruments
.
memory_summary_by_account_by_event_name
имеет столбцы
USER
, HOST
и EVENT_NAME
. Каждая строка
суммирует события для сделанного отчета (комбинация пользователя и
узла) и имя событий.
memory_summary_by_host_by_event_name
имеет столбцы
HOST
и EVENT_NAME
.
Каждая строка суммирует события для данного узла и имени событий.
memory_summary_by_thread_by_event_name
имеет столбцы
THREAD_ID
и EVENT_NAME
.
Каждая строка суммирует события для данного потока и имени событий.
memory_summary_by_user_by_event_name
имеет столбцы
USER
и EVENT_NAME
. Каждая строка суммирует события
для данного пользователя и имени событий.
memory_summary_global_by_event_name
имеет столбец
EVENT_NAME
. Каждая строка суммирует события для
данного имени событий.У каждой сводной таблицы памяти есть эти сводные столбцы, содержащие соединенные значения:
COUNT_ALLOC
, COUNT_FREE
Соединенные числа вызовов функций, подобных malloc и free.
SUM_NUMBER_OF_BYTES_ALLOC
,
SUM_NUMBER_OF_BYTES_FREE
Соединенные размеры выделенных и освобожденных блоков памяти.
CURRENT_COUNT_USED
Соединенное число в настоящее время выделяемых блоков, которые еще не были
освобождены. Это столбец удобства, равный
COUNT_ALLOC
- COUNT_FREE
.
CURRENT_NUMBER_OF_BYTES_USED
Соединенный размер в настоящее время выделяемых блоков памяти, которые еще
не были освобождены. Это столбец удобства, равный
SUM_NUMBER_OF_BYTES_ALLOC
-SUM_NUMBER_OF_BYTES_FREE
.
LOW_COUNT_USED
, HIGH_COUNT_USED
Метки, соответствующие столбцу CURRENT_COUNT_USED
.
LOW_NUMBER_OF_BYTES_USED
,
HIGH_NUMBER_OF_BYTES_USED
Метки, соответствующие столбцу CURRENT_NUMBER_OF_BYTES_USED
.
Сводные таблицы памяти имеют индексы:
memory_summary_by_account_by_event_name
:
Первичный ключ на (USER
,
HOST
, EVENT_NAME
).
memory_summary_by_host_by_event_name
:
Первичный ключ на (HOST
,
EVENT_NAME
).
memory_summary_by_thread_by_event_name
:
Первичный ключ на (THREAD_ID
,
EVENT_NAME
).
memory_summary_by_user_by_event_name
:
Первичный ключ на (USER
,
EVENT_NAME
).
memory_summary_global_by_event_name
:
Первичный ключ на (EVENT_NAME
).
TRUNCATE TABLE
позволен
на сводных таблицах памяти. Это имеет эффекты:
Вообще, усечение сбрасывает базовую линию для статистики, но не изменяет состояние сервера. Таким образом, усечение таблицы памяти не освобождает память.
COUNT_ALLOC
и COUNT_FREE
сброшены к новой базовой линии, уменьшая каждый счетчик тем
же самым значением.SUM_NUMBER_OF_BYTES_ALLOC
и
SUM_NUMBER_OF_BYTES_FREE
сброшены к новой базовой линии.LOW_COUNT_USED
и HIGH_COUNT_USED
сброшены к CURRENT_COUNT_USED
.LOW_NUMBER_OF_BYTES_USED
и
HIGH_NUMBER_OF_BYTES_USED
сброшены к
CURRENT_NUMBER_OF_BYTES_USED
.Кроме того, каждая сводная таблица памяти, которая соединена с учетной
записью, узлом, пользователем или потоком, является неявно усеченной
усечением таблицы, от которой зависит, или усечением
memory_summary_global_by_event_name
. Для деталей см.
раздел 23.9.8.
Большинство инструментов памяти отключено по умолчанию и может быть
включено или отключено динамически, обновляя столбец ENABLED
соответствующих инструментов в
setup_instruments
. У инструментов памяти есть названия формы
memory/
.code_area
/instrument_name
Чтобы включить все инструменты памяти, выполните этот запрос:
mysql> UPDATE setup_instruments SET ENABLED='YES' WHERE NAME LIKE 'memory/%';
Инструменты с приставкой memory/performance_schema/
показывают, сколько памяти выделено для внутренних буферов в
Performance Schema непосредственно. Инструменты
memory/performance_schema/
встроены, всегда включаются и не
могут быть отключены при запуске или во время выполнения. Встроенные
инструменты памяти выведены на экран только в таблице
memory_summary_global_by_event_name
.
Для инструментов памяти столбец TIMED
в
setup_instruments
проигнорирован, потому что операции памяти не рассчитаны.
Когда поток в сервере выполняет распределение памяти, которое было инструментовано, эти правила применяются:
Если поток не инструментован или инструмент памяти не включен, выделенный блок памяти не инструментован.
Для освобождения применяются эти правила:
Если поток инструментован, а блок памяти не инструментован, освобождение не инструментовано, никакие статистические данные не изменены.
Для статистики по потокам применяются следующие правила.
Когда инструментованный блок памяти размера
N
выделен, Performance Schema
делает эти обновления столбцов сводной таблицы памяти:
COUNT_ALLOC
: увеличен на 1.
CURRENT_COUNT_USED
: увеличен на 1.HIGH_COUNT_USED
: увеличен, если
CURRENT_COUNT_USED
новый максимум.SUM_NUMBER_OF_BYTES_ALLOC
: увеличен на
N
.CURRENT_NUMBER_OF_BYTES_USED
:
увеличен на N
.HIGH_NUMBER_OF_BYTES_USED
: увеличен, если
CURRENT_NUMBER_OF_BYTES_USED
новый максимум.Когда инструментованный блок памяти освобожден, Performance Schema делает эти обновления столбцов сводной таблицы памяти:
COUNT_FREE
: увеличен на 1.
CURRENT_COUNT_USED
: уменьшен на 1.LOW_COUNT_USED
: уменьшена, если
CURRENT_COUNT_USED
новый минимум.SUM_NUMBER_OF_BYTES_FREE
: увеличен на
N
.CURRENT_NUMBER_OF_BYTES_USED
:
уменьшен на N
.LOW_NUMBER_OF_BYTES_USED
: уменьшен, если
CURRENT_NUMBER_OF_BYTES_USED
новый минимум.Для высокоуровневых совокупностей (глобальной, учетной записи, пользователя, узла) те же самые правила применяются.
LOW_COUNT_USED
и
LOW_NUMBER_OF_BYTES_USED
более низкие оценки. Значение, о
котором сообщает Performance Schema, будет меньше чем или равно самому
низкому размеру памяти, эффективно используемой во время выполнения.
HIGH_COUNT_USED
и
HIGH_NUMBER_OF_BYTES_USED
более высокие оценки. Значение, о котором сообщает Performance Schema,
будет больше чем или равным самому высокому размеру памяти, эффективно
используемой во время выполнения.Для более низких оценок в сводных таблицах кроме
memory_summary_global_by_event_name
,
возможны отрицательные значения, если память передана между потоками.
Вот пример оценочного вычисления, отметьте, что оценочное выполнение подвержено изменениям:
Поток 1 использует память в диапазоне от 1 МБ до 2 МБ во время выполнения,
как сообщают столбцы LOW_NUMBER_OF_BYTES_USED
и
HIGH_NUMBER_OF_BYTES_USED
в
memory_summary_by_thread_by_event_name
.
Поток 2 использует память в диапазоне от 10 МБ до 12 МБ во время выполнения.
Когда эти два потока принадлежат той же самой учетной записи пользователя,
резюме на учетную запись оценивает, что эта учетная запись использовала
память в диапазоне от 11 МБ до 14 МБ. Таким образом,
LOW_NUMBER_OF_BYTES_USED
как высокоуровневая совокупность это
сумма всех LOW_NUMBER_OF_BYTES_USED
(принятие худшего случая).
Аналогично HIGH_NUMBER_OF_BYTES_USED
как
высокоуровневая совокупность это сумма всех
HIGH_NUMBER_OF_BYTES_USED
(принятие худшего случая).
11MB более низкая оценка, которая может произойти, только если оба потока в то же самое время проходят низкую метку использования.
14MB более высокая оценка, которая может произойти, только если оба потока в то же самое время проходят высокую метку использования.
Реальное использование памяти для этой учетной записи, возможно, было в диапазоне от 11.5MB до 13.5MB.
Для планирования мощностей, сообщение о худшем случае фактически желаемое поведение, поскольку это показывает то, что может потенциально произойти, когда сеансы являются некоррелироваными, что, как правило, имеет место.
Performance Schema поддерживает сводные таблицы для того, чтобы соединить статистическую информацию об ошибках и предупреждениях сервера. Для списка ошибок сервера см. раздел B.3.
Сбором информации об ошибке управляет инструмент error
,
который включен по умолчанию. Информация синхронизации не собрана.
У каждой сводной таблицы есть три столбца, которые идентифицируют ошибку:
ERROR_NUMBER
числовое значение
ошибки. Значение уникально.
ERROR_NAME
символическое имя, соответствующее
ERROR_NUMBER
. Значение уникально.SQLSTATE
значение SQLSTATE, соответствующее
ERROR_NUMBER
. Значение не обязательно уникально.Например, если ERROR_NUMBER
1050, ERROR_NAME
ER_TABLE_EXISTS_ERROR
и SQLSTATE
42S01
.
Информация о резюме событий в качестве примера:
mysql> SELECT * FROM events_errors_summary_global_by_error WHERE SUM_ERROR_RAISED <> 0\G *************************** 1. row *************************** ERROR_NUMBER: 1064 ERROR_NAME: ER_PARSE_ERROR SQL_STATE: 42000 SUM_ERROR_RAISED: 1 SUM_ERROR_HANDLED: 0 FIRST_SEEN: 2016-06-28 07:34:02 LAST_SEEN: 2016-06-28 07:34:02 *************************** 2. row *************************** ERROR_NUMBER: 1146 ERROR_NAME: ER_NO_SUCH_TABLE SQL_STATE: 42S02 SUM_ERROR_RAISED: 2 SUM_ERROR_HANDLED: 0 FIRST_SEEN: 2016-06-28 07:34:05 LAST_SEEN: 2016-06-28 07:36:18 *************************** 3. row *************************** ERROR_NUMBER: 1317 ERROR_NAME: ER_QUERY_INTERRUPTED SQL_STATE: 70100 SUM_ERROR_RAISED: 1 SUM_ERROR_HANDLED: 0 FIRST_SEEN: 2016-06-28 11:01:49 LAST_SEEN: 2016-06-28 11:01:49
У каждой сводной таблицы есть один или более группирующихся столбцов, чтобы указать как табличные ошибки объединяются:
events_errors_summary_by_account_by_error
имеет столбцы
USER
, HOST
и ERROR_NUMBER
.
Каждая строка суммирует события для сделанного отчета (комбинация
пользователя и узла) и ошибки.
events_errors_summary_by_host_by_error
имеет столбцы
HOST
и ERROR_NUMBER
.
Каждая строка суммирует события для данного узла и ошибки.
events_errors_summary_by_thread_by_error
имеет столбцы
THREAD_ID
и ERROR_NUMBER
.
Каждая строка суммирует события для данного потока и ошибки.
events_errors_summary_by_user_by_error
имеет столбцы
USER
и ERROR_NUMBER
.
Каждая строка суммирует события для данного пользователя и ошибки.
events_errors_summary_global_by_error
имеет столбец
ERROR_NUMBER
. Каждая строка суммирует события для данной ошибки.
У каждой сводной таблицы есть эти сводные столбцы, содержащие соединенные значения:
SUM_ERROR_RAISED
Этот столбец показывает, сколько раз ошибка произошла.
SUM_ERROR_HANDLED
Этот столбец показывает, сколько раз ошибка была обработана обработчиком исключения SQL.
FIRST_SEEN
, LAST_SEEN
Timestamp, указывающий, когда ошибка была замечена в первый и в последний раз.
Строка NULL
в каждой сводной таблице нужна для
совокупной статистики для всех ошибок, которые лежат вне диапазона
инструментованных ошибок. Например, если ошибки MySQL Server
находятся в диапазоне от M
до
N
и ошибка поднята с номером
Q
не в этом диапазоне, ошибка показана в строке
NULL
. Это строка с ERROR_NUMBER=0
,
ERROR_NAME=NULL
и SQLSTATE=NULL
.
Сводные таблицы ошибок имеют индексы:
events_errors_summary_by_account_by_error
:
Первичный ключ на (USER
,
HOST
, ERROR_NUMBER
).
events_errors_summary_by_host_by_error
:
Первичный ключ на (HOST
,
ERROR_NUMBER
).
events_errors_summary_by_thread_by_error
:
Первичный ключ на (THREAD_ID
,
ERROR_NUMBER
).
events_errors_summary_by_user_by_error
:
Первичный ключ на (USER
,
ERROR_NUMBER
).
events_errors_summary_global_by_error
:
Первичный ключ на (ERROR_NUMBER
).
TRUNCATE TABLE
позволен
на сводных таблицах ошибок. Это имеет эффекты:
Для сводных таблиц, не соединенных учетной записью, узлом или
пользователем, усечение сбрасывает сводные столбцы к нолю или
NULL
вместо того, чтобы удалять строки.
NULL
для остающихся строк.Кроме того, каждая сводная таблица, которая соединена учетной записью,
узлом, пользователем или потоком, является неявно усеченной усечением таблицы
соединения, от которой зависит, или усечением
events_errors_summary_global_by_error
. Детали в
разделе 23.9.8.
Значение системной переменной
show_compatibility_56
затрагивает информацию, доступную из
таблиц, описанных здесь. Для деталей см. описание этой переменной в
разделе 6.1.5.
Performance Schema делает доступной информацию о переменных состояния в таблицах, описанных в разделе 23.9.14. Это также делает соединенную информацию о переменной состояния доступной в сводных таблицах, описанных здесь. У каждой сводной таблицы переменной состояния есть один или более группирующихся столбцов, чтобы указать, как таблица агрегирует переменные:
status_by_account
имеет столбцы
USER
, HOST
и VARIABLE_NAME
,
чтобы суммировать переменные состояния учетной записью.
status_by_host
имеет столбцы
HOST
и VARIABLE_NAME
, чтобы суммировать переменные
состояния узлом, от которого соединялись клиенты.status_by_user
имеет столбцы
USER
и VARIABLE_NAME
, чтобы суммировать переменные
состояния именем пользователя клиента.У каждой сводной таблицы переменных состояния есть этот сводный столбец, содержащий соединенные значения:
VARIABLE_VALUE
Соединенное значение переменной состояния для активных и законченных сеансов.
Сводные таблицы переменной состояния имеют индексы:
Первичный ключ на (USER
,
HOST
, VARIABLE_NAME
).
Первичный ключ на (HOST
,
VARIABLE_NAME
).
Первичный ключ на (USER
,
VARIABLE_NAME
).
Смысл account в этих таблицах подобно его значению в таблицах
привилегий MySQL системной базы данных mysql
,
в том смысле, что термин относится к комбинации значений узла и пользователя.
Они отличаются тем, что для таблиц привилегий часть узла учетной записи может
быть образцом, тогда как для Performance Schema значение узла всегда
определенное имя хоста.
Состояние учетной записи собрано, когда сеансы заканчиваются. Счетчики состояния сеанса добавлены к глобальным счетчикам состояния и соответствующим счетчикам состояния учетной записи. Если статистические данные учетной записи не собраны, состояние сеанса добавлено к состояниям хоста и пользователя, если узел и пользовательское состояние собираются.
Учетная запись, узел и пользовательская статистика не собраны, если
переменные
performance_schema_accounts_size
,
performance_schema_hosts_size
и
performance_schema_users_size
, соответственно, установлены в 0.
Performance Schema поддерживает
TRUNCATE TABLE
для сводных таблиц переменных состояния следующим
образом, во всех случаях состояние для активных сеансов не затронуто:
status_by_account
: Совокупности считают состояние от
законченных сеансов до пользователя и размещают состояние, затем сбрасывает
состояние учетной записи.
status_by_host
:
Сброс состояний узла от законченных сеансов.status_by_user
:
Сброс состояний пользователя от законченных сеансов.FLUSH STATUS
добавляет состояние сеанса от всех активных сеансов к глобальным переменным
состояния, сбрасывает состояние всех активных сеансов и сбрасывает учетную
запись, узел и пользовательские значения состояния от разъединенных сеансов.
Следующие разделы описывают таблицы, которые не попадают в табличные категории, обсужденные в предыдущих разделах:
host_cache
:
Информация от внутреннего кэша узла.
performance_timers
: Какие таймеры событий доступны.threads
:
Информация о потоках сервера.Таблица host_cache
обеспечивает доступ к содержанию кэша узла, который содержит имя хоста
клиента и информацию об IP-адресе и используется, чтобы избежать поисков DNS
(см. раздел 9.12.4.2).
host_cache
выставляет содержание кэша узла так, чтобы это могло быть исследовано,
используя SELECT
. Performance
Schema должна быть включена, или эта таблица пуста.
У host_cache
есть эти столбцы:
IP
IP-адрес клиента, который соединялся с сервером, выраженный как строка.
HOST
Имя хоста DNS для IP клиента или NULL
,
если имя неизвестно.
HOST_VALIDATED
Было ли разрешение DNS "имя к IP" или "IP к узлу" выполнено успешно для
IP клиента. Если HOST_VALIDATED
= YES
,
HOST
используется в качестве имени хоста, соответствующего IP
так, чтобы вызовов DNS можно было избежать. В то время, как
HOST_VALIDATED
= NO
, разрешение DNS
предпринято снова для каждого соединения, пока оно в конечном счете не
завершается с допустимым результатом или с постоянной ошибкой.
Эта информация позволяет серверу избежать плохого кэширования или пропуска
имени хоста во время временных отказов DNS, которые затронули
бы клиентов навсегда.
SUM_CONNECT_ERRORS
Число ошибок соединения, которые считаются
blocking (оценены относительно переменной
max_connect_errors
). Только ошибки квитирования протокола посчитаны и только для
узлов, которые передали проверку допустимости
(HOST_VALIDATED = YES
).
COUNT_HOST_BLOCKED_ERRORS
Число соединений, которые были заблокированы потому, что
SUM_CONNECT_ERRORS
превышает значение переменной
of the
max_connect_errors
.
COUNT_NAMEINFO_TRANSIENT_ERRORS
Число переходных ошибок во время разрешения DNS IP к имени хоста.
COUNT_NAMEINFO_PERMANENT_ERRORS
Число постоянных ошибок во время разрешения DNS IP к имени хоста.
COUNT_FORMAT_ERRORS
Число ошибок формата имени хоста. MySQL не выполняет соответствие
значения столбцов Host
в mysql.user
именам хоста, для которых один или больше начальных компонентов имени
являются полностью числовыми (1.2.example.com
).
IP-адрес клиента используется вместо этого. Для объяснения, почему этот тип
соответствия не происходит, см. раздел
7.2.3.
COUNT_ADDRINFO_TRANSIENT_ERRORS
Число переходных ошибок во время разрешения DNS имени хоста к IP.
COUNT_ADDRINFO_PERMANENT_ERRORS
Число постоянных ошибок во время разрешения DNS имени хоста к IP.
COUNT_FCRDNS_ERRORS
Число передовых подтвержденных обратных ошибок DNS. Эти ошибки происходят, когда разрешение DNS производит IP-адрес, который не соответствует клиенту, порождающему IP-адрес.
COUNT_HOST_ACL_ERRORS
Число ошибок, которые происходят, потому что никакой пользователь с хоста
клиента не может возможно войти в систему. В таких случаях сервер
возвращает
ER_HOST_NOT_PRIVILEGED
и даже не просит имя
пользователя или пароль.
COUNT_NO_AUTH_PLUGIN_ERRORS
Число ошибок из-за запросов о недоступном плагине аутентификации. Плагин может быть недоступным, если, например, он никогда не загружался, или попытка загрузки провалилась.
COUNT_AUTH_PLUGIN_ERRORS
Число ошибок, сообщенных плагинами аутентификации.
Плагин аутентификации может сообщить, различные коды ошибки, которые
указывают на первопричину отказа. В зависимости от типа ошибки увеличен один
из этих столбцов: COUNT_AUTHENTICATION_ERRORS
,
COUNT_AUTH_PLUGIN_ERRORS
,
COUNT_HANDSHAKE_ERRORS
. Новые коды возвращения это
дополнительное расширение к существующему API. Неизвестные или неожиданные
ошибки включены в столбец COUNT_AUTH_PLUGIN_ERRORS
.
COUNT_HANDSHAKE_ERRORS
Число ошибок обнаружено на проводном уровне протокола.
COUNT_PROXY_USER_ERRORS
Число ошибок обнаружило, когда proxy-пользователь A передает доступ другому пользователю B, который не существует.
COUNT_PROXY_USER_ACL_ERRORS
Число ошибок, когда proxy-пользователь A передает доступ другому
пользователю B, который действительно существует, но для кого A не имеет
привилегии PROXY
.
COUNT_AUTHENTICATION_ERRORS
Число ошибок вызвано неудавшейся аутентификацией.
COUNT_SSL_ERRORS
Число ошибок из-за проблем SSL.
COUNT_MAX_USER_CONNECTIONS_ERRORS
Число ошибок вызвано превышением доли соединения в расчёте на пользователя. См. раздел 7.3.5.
COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS
Число ошибок вызвано, превышая доли соединений-за-час в расчёте на пользователя. См. раздел 7.3.5.
COUNT_DEFAULT_DATABASE_ERRORS
Число ошибок, связанных с базой данных по умолчанию. Например, база данных не существовала, или у пользователя не было никаких привилегий для того, чтобы получить доступ к ней.
COUNT_INIT_CONNECT_ERRORS
Число ошибок, вызванных отказами выполнения запросов в
init_connect
.
COUNT_LOCAL_ERRORS
Число ошибок, локальных к выполнению сервера и не связанных с сетью, аутентификацией или разрешением. Например, условия переполнения памяти попадают в эту категорию.
COUNT_UNKNOWN_ERRORS
Число других, неизвестных ошибок, не составляемых другими столбцами в этой
таблице. Этот столбец сохранен для будущего использования, в случае, если о
новых состояниях ошибки нужно сообщить, сохраняя обратную совместимость и
структуру таблицы host_cache
.
FIRST_SEEN
timestamp первой попытки соединения, замеченной
от клиента в IP
.
LAST_SEEN
timestamp последней попытки соединения, замеченной
от клиента в IP
.
FIRST_ERROR_SEEN
timestamp первой ошибки, замеченной от клиента в IP
.
LAST_ERROR_SEEN
timestamp последней ошибки, замеченной от клиента в IP
.
У host_cache
есть эти индексы:
Первичный ключ на (IP
).
HOST
).FLUSH HOSTS
и
TRUNCATE TABLE host_cache
имеют тот же самый эффект: они очищают кэш узла. Это также удаляет строки из
host_cache
(потому что это видимое представление кэша) и открывает любые заблокированные
узлы (см. раздел B.5.2.5).
FLUSH HOSTS
требует привилегии
RELOAD
.
TRUNCATE TABLE
требует
привилегии DROP
для
host_cache
.
performance_timers
показывает, какие таймеры событий доступны:
mysql> SELECT * FROM performance_timers; +-------------+-----------------+------------------+----------------+ | TIMER_NAME | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD | +-------------+-----------------+------------------+----------------+ | CYCLE | 2389029850 | 1 | 72 | | NANOSECOND | 1000000000 | 1 | 112 | | MICROSECOND | 1000000 | 1 | 136 | | MILLISECOND | 1036 | 1 | 168 | | TICK | 105 | 1 | 2416 | +-------------+-----------------+------------------+----------------+
Таймеры в setup_timers
, которые Вы можете использовать, не имеют NULL
в других столбцах. Если значения, связанные с данным именем таймера,
NULL
, этот таймер не поддержан на Вашей платформе.
У performance_timers
есть эти столбцы:
TIMER_NAME
Имя, которым можно обратиться к таймеру, конфигурируя
setup_timers
.
TIMER_FREQUENCY
Число модулей таймера в секунду. Для счетчика циклов частота вообще
связана со скоростью центрального процессора. Например, на системе с 2.4GHz
процессором CYCLE
может быть близко к 2400000000.
TIMER_RESOLUTION
Указывает на число модулей таймера, которыми таймер оценивает увеличение. Если у таймера есть разрешение 10, его значение увеличено на 10 каждый раз.
TIMER_OVERHEAD
Минимальное число циклов, чтобы получить одну синхронизацию с данным таймером. Performance Schema определяет это значение, вызывая таймер 20 раз во время инициализации и выбирая самое маленькое значение. Общее количество циклов дважды это количество, потому что инструментовка вызывает таймер в запуске и конце каждого случая. Код таймера называют только для рассчитанных событий, таким образом, это не влияет на нерассчитанные события.
TRUNCATE TABLE
не
позволен для
performance_timers
.
Таблица threads
содержит строку для каждого потока сервера. Каждая строка содержит информацию
о потоке и указывает, включен ли контроль и журналирование событий:
mysql> SELECT * FROM threads\G *************************** 1. row *************************** THREAD_ID: 1 NAME: thread/sql/main TYPE: BACKGROUND PROCESSLIST_ID: NULL PROCESSLIST_USER: NULL PROCESSLIST_HOST: NULL PROCESSLIST_DB: NULL PROCESSLIST_COMMAND: NULL PROCESSLIST_TIME: 80284 PROCESSLIST_STATE: NULL PROCESSLIST_INFO: NULL PARENT_THREAD_ID: NULL ROLE: NULL INSTRUMENTED: YES HISTORY: YES CONNECTION_TYPE: NULL THREAD_OS_ID: 489803 ... *************************** 4. row *************************** THREAD_ID: 51 NAME: thread/sql/one_connection TYPE: FOREGROUND PROCESSLIST_ID: 34 PROCESSLIST_USER: isabella PROCESSLIST_HOST: localhost PROCESSLIST_DB: performance_schema PROCESSLIST_COMMAND: Query PROCESSLIST_TIME: 0 PROCESSLIST_STATE: Sending data PROCESSLIST_INFO: SELECT * FROM threads PARENT_THREAD_ID: 1 ROLE: NULL INSTRUMENTED: YES HISTORY: YES CONNECTION_TYPE: SSL/TLS THREAD_OS_ID: 755399 ...
Когда Performance Schema инициализируется, она заполняет
threads
, основываясь на
существующих потоках. После этого новая строка добавлена каждый раз, когда
сервер создает поток.
Столбцы INSTRUMENTED
и HISTORY
для новых потоков определены содержанием
setup_actors
.
Для информации о том, как использовать
setup_actors
, чтобы
управлять этими столбцами, см.
раздел 23.2.3.6.
Удаление строк из threads
происходит, когда потоки заканчиваются. Для потока, связанного с сеансом
клиента, происходит удаление, когда сеанс заканчивается. Если клиент имеет
включенную опцию auto-reconnect, и сеанс повторно соединяется после
разъединения, то этот сеанс становится связанным с новой строкой в
threads
, у которой есть
другой PROCESSLIST_ID
. Значения INSTRUMENTED
и
HISTORY
для нового потока
могут отличаться от таковых из оригинального потока:
setup_actors
,
возможно, изменилась тем временем, и если
INSTRUMENTED
или HISTORY
для оригинального потока было изменено после того, как строка была
инициализирована, изменение не переносится на новый поток.
Столбцы таблицы threads
с именами, имеющими приставку PROCESSLIST_
,
предоставляют информацию, подобную доступной из
INFORMATION_SCHEMA.PROCESSLIST
или SHOW PROCESSLIST
. Таким образом, все три источника предоставляют контролирующую
поток информацию. Использование
threads
отличается от использования других двух источников:
Доступ к threads
не требует mutex и оказывает минимальное влияние на работу сервера.
INFORMATION_SCHEMA.PROCESSLIST
и SHOW PROCESSLIST
имеют отрицательные исполнительные последствия, потому что
они требуют mutex.
threads
обеспечивает дополнительную информацию для каждого потока, такую как является
ли это фоновым потоком и местоположение в пределах
сервера, связанное с потоком.threads
предоставляет информацию о фоновых потоках, таким образом, она может
использоваться, чтобы контролировать деятельность, чего другие источники
информации о потоке не могут.INSTRUMENTED
и HISTORY
для новых потоков переднего плана, используйте
setup_actors
.
Чтобы управлять этими аспектами существующих потоков, установите столбцы
INSTRUMENTED
и HISTORY
строк таблицы
threads
.По этим причинам, DBA выполняет контроль сервера, используя
INFORMATION_SCHEMA.PROCESSLIST
или SHOW PROCESSLIST
и может хотеть контролировать, используя вместо этого
threads
.
Для
INFORMATION_SCHEMA.PROCESSLIST
и SHOW PROCESSLIST
информацию о потоках для других пользователей показывают, только если текущий
пользователь имеет привилегию
PROCESS
.
Это не так для таблицы threads
: все строки показывают любому пользователю, который имеет
привилегию SELECT
для таблицы. Пользователям, которые не должны
быть в состоянии видеть потоки для других пользователей, нельзя
давать эту привилегию.
У threads
есть эти столбцы:
THREAD_ID
Уникальный идентификатор потока.
NAME
Имя, связанное с кодом инструментовки потока в сервере. Например,
thread/sql/one_connection
соответствует функции потока в коде,
ответственном за обработку пользовательского соединения, а
thread/sql/main
для функции main()
сервера.
TYPE
Тип потока: FOREGROUND
или BACKGROUND
.
Пользовательские потоки соединения это потоки переднего плана. Потоки,
связанные с внутренней деятельностью сервера, являются фоновыми потоками.
PROCESSLIST_ID
Для потоков, которые выведены на экран в
INFORMATION_SCHEMA.PROCESSLIST
это значение столбца ID
этой таблицы.
Это также значение, выведенное на экран в столбце Id
вывода
SHOW PROCESSLIST
и
значение, возвращаемое функцией
CONNECTION_ID()
для потока.
Для фоновых потоков (потоки, не связанные с пользовательским соединением),
PROCESSLIST_ID
NULL
,
таким образом, значения не уникальны.
PROCESSLIST_USER
Пользователь, связанный с потоком переднего плана, NULL
для фонового потока.
PROCESSLIST_HOST
Имя хоста клиента, связанного с потоком переднего плана,
NULL
для фонового потока.
В отличие от столбца HOST
в INFORMATION_SCHEMA
,
PROCESSLIST
или
столбец Host
вывода
SHOW PROCESSLIST
,
столбец PROCESSLIST_HOST
не включает номер порта для соединений
TCP/IP. Чтобы получить эту информацию из Performance Schema,
включите инструментовку сокета (которая не включена по умолчанию) и
исследуйте таблицу
socket_instances
:
mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'wait/io/socket%'; +----------------------------------------+---------+-------+ | NAME | ENABLED | TIMED | +----------------------------------------+---------+-------+ | wait/io/socket/sql/server_tcpip_socket | NO | NO | | wait/io/socket/sql/server_unix_socket | NO | NO | | wait/io/socket/sql/client_connection | NO | NO | +----------------------------------------+---------+-------+ 3 rows in set (0.01 sec) mysql> UPDATE setup_instruments SET ENABLED='YES' WHERE NAME LIKE 'wait/io/socket%'; Query OK, 3 rows affected (0.00 sec) Rows matched: 3 Changed: 3 Warnings: 0 mysql> SELECT * FROM socket_instances\G *************************** 1. row *************************** EVENT_NAME: wait/io/socket/sql/client_connection OBJECT_INSTANCE_BEGIN: 140612577298432 THREAD_ID: 31 SOCKET_ID: 53 IP: ::ffff:127.0.0.1 PORT: 55642 STATE: ACTIVE ...
PROCESSLIST_DB
База данных значения по умолчанию для потока или
NULL
, если нет.
PROCESSLIST_COMMAND
Для потоков переднего плана команда выполняется от имени клиента или
Sleep
, если сессия спит. Для описаний команд потока см.
раздел 9.14.
Значение этого столбца соответствует командам
COM_
протокола клиент-сервер и
переменным состояния xxx
Com_
. См.
раздел 6.1.7.xxx
Фоновые потоки не выполняют команды от имени клиентов, таким образом,
этот столбец может быть NULL
.
PROCESSLIST_TIME
Время в секундах, которое поток был в его текущем состоянии.
PROCESSLIST_STATE
Действие, случай или состояние, которое указывает на то, что делает поток.
Для описания значений PROCESSLIST_STATE
см.
раздел 9.14. Если значение
NULL
, поток может соответствовать неактивному сеансу клиента,
или работа, которую он делает, не инструментована с этапами.
Большинство состояний соответствует очень быстрым операциям. Если поток остается в данном статусе в течение многих секунд, может быть проблема.
PROCESSLIST_INFO
Запрос, который поток выполняет, или NULL
,
если это не выполняет запросы. Запрос мог быть послан в сервер или внутренним
запросом, если запрос выполняет другие запросы. Например, если
CALL
выполняет хранимую процедуру, которая выполняет
SELECT
, значение
PROCESSLIST_INFO
показывает запрос
SELECT
.
PARENT_THREAD_ID
Если этот поток подпоток (порожденный другим потоком), это
THREAD_ID
основного потока.
ROLE
Не используется.
INSTRUMENTED
Инструментованы ли события, запущенные потоком.
Значения YES
или NO
.
Для потоков переднего плана, начальное значение
INSTRUMENTED
определено тем, соответствует ли учетная запись
пользователя, связанная с потоком, какой-либо строке в
setup_actors
.
Соответствие основано на значениях
PROCESSLIST_USER
и PROCESSLIST_HOST
.
Если поток порождает подпоток, соответствие происходит снова для
строки таблицы threads
,
созданной для подпотока.
INSTRUMENTED
YES
по умолчанию. setup_actors
не консультируется, потому что нет никакого связанного
пользователя для фоновых потоков.INSTRUMENTED
может быть изменено во время жизни потока.Для того, чтобы контролировать события, запущенные потоком, эти вещи должны быть истиной:
Потребитель thread_instrumentation
в
setup_consumers
должен быть YES
.
threads.INSTRUMENTED
должен быть YES
.
ENABLED
YES
в
setup_instruments
.HISTORY
Зарегистрировать ли исторические события для потока. Значения
YES
или NO
.
Для потоков переднего плана, начальное значение
HISTORY
определено тем, соответствует ли учетная запись
пользователя, связанная с потоком, какой-либо строке в
setup_actors
.
Соответствие основано на значениях
PROCESSLIST_USER
и PROCESSLIST_HOST
.
Если поток порождает подпоток, соответствие происходит снова для
строки таблицы threads
,
созданной для подпотока.
HISTORY
YES
по умолчанию.
setup_actors
не консультируется, потому что нет никакого связанного пользователя
для фоновых потоков.HISTORY
может быть изменено во время жизни потока.Для журналирования исторического события для потока, эти вещи должны быть истиной:
Соответствующие связанные с историей потребители в
setup_consumers
должны быть включены. Например, случай ожидания, протоколируемый в
таблицах
events_waits_history
и
events_waits_history_long
требует соответствующих потребителй
events_waits_history
и
events_waits_history_long
в YES
.
threads.HISTORY
должен быть YES
.ENABLED
YES
в
setup_instruments
.CONNECTION_TYPE
Протокол, по которому установлено соединение, или
NULL
для фоновых потоков. Разрешенные значения:
TCP/IP
(соединение TCP/IP, установленное без SSL),
SSL/TLS
(соединение TCP/IP, установленное с SSL),
Socket
(соединение файла сокета Unix),
Named Pipe
(соединение канала Windows) и Shared Memory
(соединение совместно используемой памяти Windows).
THREAD_OS_ID
Поток или идентификатор задачи как определено основной операционной системой, если есть:
Когда поток MySQL связан с тем же самым потоком операционной
системы, THREAD_OS_ID
содержит ID потока операционной системы.
THREAD_OS_ID
NULL
.
Это типично для пользовательских сеансов, когда плагин потока используется
(см. MySQL Enterprise Thread Pool).Для Windows THREAD_OS_ID
соответствует ID потока,
видимому в Process Explorer
(https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
).
Для Linux THREAD_OS_ID
соответствует значению
функции gettid()
. Это значение выставлено, например, используя
команды perf или ps -L
или в файловой системе proc
(/proc/
). Для получения дополнительной информации см.
[pid]
/task/[tid]
perf-stat(1)
, ps(1)
и proc(5)
.
У threads
есть эти индексы:
Первичный ключ на (THREAD_ID
).
NAME
).PROCESSLIST_ID
).PROCESSLIST_USER
,
PROCESSLIST_HOST
).PROCESSLIST_HOST
).THREAD_OS_ID
).TRUNCATE TABLE
не
позволен для threads
.
Таблица 23.3. Обзор переменных Performance Schema
Параметры Performance Schema могут быть определены при запуске сервера в командной строке или в файлах опции, чтобы сконфигурировать инструменты и потребителей Performance Schema. Конфигурация во время выполнения также возможна во многих случаях (см. раздел 23.2.3 ), но конфигурация запуска должна использоваться, когда конфигурация во время выполнения должна слишком поздно затронуть инструменты, которые были уже инициализированы во время процесса запуска.
Потребители и инструменты Performance Schema могут быть сконфигурированы при запуске, используя следующий синтаксис. Для дополнительных деталей см. раздел 23.2.2 .
--performance-schema-consumer-
consumer_name
=value
Сконфигурируйте потребителя Performance Schema. Имена потребителей в
setup_consumers
используют подчеркивания, но для указания потребителя при запуске тире и
подчеркиваниях в пределах имени эквивалентны. Опции для того, чтобы
сконфигурировать отдельных потребителей детализированы позже в этом разделе.
--performance-schema-instrument=instrument_name
=value
Сконфигурируйте инструмент Performance Schema. Имя может быть дано как образец, чтобы сконфигурировать инструменты, которые соответствуют образцу.
Следующие элементы конфигурируют отдельных потребителей:
--performance-schema-consumer-events-stages-current=
value
Сконфигурируйте потребитель events-stages-current
.
--performance-schema-consumer-events-stages-history=value
Сконфигурируйте потребитель events-stages-history
.
--performance-schema-consumer-events-stages-history-long=value
Сконфигурируйте потребитель events-stages-history-long
.
--performance-schema-consumer-events-statements-current=value
Сконфигурируйте потребитель events-statements-current
.
--performance-schema-consumer-events-statements-history=value
Сконфигурируйте потребитель events-statements-history
.
--performance-schema-consumer-events-statements-history-long=value
Сконфигурируйте потребитель events-statements-history-long
.
--performance-schema-consumer-events-transactions-current=value
Сконфигурируйте потребитель events-transactions-current
.
--performance-schema-consumer-events-transactions-history=value
Сконфигурируйте потребитель Performance Schema
events-transactions-history
.
--performance-schema-consumer-events-transactions-history-long=
value
Сконфигурируйте потребитель Performance Schema
events-transactions-history-long
.
--performance-schema-consumer-events-waits-current=value
Сконфигурируйте потребитель events-waits-current
.
--performance-schema-consumer-events-waits-history=value
Сконфигурируйте потребитель events-waits-history
.
--performance-schema-consumer-events-waits-history-long=value
Сконфигурируйте потребитель events-waits-history-long
.
--performance-schema-consumer-global-instrumentation=value
Сконфигурируйте потребитель global-instrumentation
.
--performance-schema-consumer-statements-digest=value
Сконфигурируйте потребитель statements-digest
.
--performance-schema-consumer-thread-instrumentation=value
Сконфигурируйте потребитель thread-instrumentation
.
осуществляет несколько системных переменных, которые предоставляют информацию о конфигурации:
mysql> SHOW VARIABLES LIKE 'perf%'; +----------------------------------------------------------+-------+ | Variable_name | Value | +----------------------------------------------------------+-------+ | performance_schema | ON | | performance_schema_accounts_size | -1 | | performance_schema_digests_size | 10000 | | performance_schema_events_stages_history_long_size | 10000 | | performance_schema_events_stages_history_size | 10 | | performance_schema_events_statements_history_long_size | 10000 | | performance_schema_events_statements_history_size | 10 | | performance_schema_events_transactions_history_long_size | 10000 | | performance_schema_events_transactions_history_size | 10 | | performance_schema_events_waits_history_long_size | 10000 | | performance_schema_events_waits_history_size | 10 | | performance_schema_hosts_size | -1 | | performance_schema_max_cond_classes | 80 | | performance_schema_max_cond_instances | -1 | | performance_schema_max_digest_length | 1024 | | performance_schema_max_file_classes | 50 | | performance_schema_max_file_handles | 32768 | | performance_schema_max_file_instances | -1 | | performance_schema_max_index_stat | -1 | | performance_schema_max_memory_classes | 320 | | performance_schema_max_metadata_locks | -1 | | performance_schema_max_mutex_classes | 200 | | performance_schema_max_mutex_instances | -1 | | performance_schema_max_prepared_statements_instances | -1 | | performance_schema_max_program_instances | -1 | | performance_schema_max_rwlock_classes | 40 | | performance_schema_max_rwlock_instances | -1 | | performance_schema_max_socket_classes | 10 | | performance_schema_max_socket_instances | -1 | | performance_schema_max_sql_text_length | 1024 | | performance_schema_max_stage_classes | 150 | | performance_schema_max_statement_classes | 192 | | performance_schema_max_statement_stack | 10 | | performance_schema_max_table_handles | -1 | | performance_schema_max_table_instances | -1 | | performance_schema_max_table_lock_stat | -1 | | performance_schema_max_thread_classes | 50 | | performance_schema_max_thread_instances | -1 | | performance_schema_session_connect_attrs_size | 512 | | performance_schema_setup_actors_size | -1 | | performance_schema_setup_objects_size | -1 | | performance_schema_users_size | -1 | +----------------------------------------------------------+-------+
Системные переменные Performance Schema могут быть установлены при запуске сервера в командной строке или в файлах опции, и многие могут быть установлены во времени выполнения. См. раздел 23.10.
Performance Schema автоматически измеряет значения нескольких из ее параметров при запуске сервера, если они не установлены явно. Для получения дополнительной информации см. раздел 23.2.2 .
У системных переменных Performance Schema есть следующие значения:
Формат командной строки | --performance_schema=# | ||
Системная | Имя |
performance_schema | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
boolean | |
Значение по умолчанию | ON |
Значение этой переменной ON
или OFF
, чтобы
указать, включена ли Performance Schema. По умолчанию значение
ON
. При запуске сервера Вы можете определить эту переменную без
значения, со значением ON
(или 1), чтобы включить или со
значением OFF
(или 0), чтобы выключить.
Даже когда Performance Schema отключена, она продолжает заполнять таблицы
populate the
global_variables
,
session_variables
,
global_status
и
session_status
.
Это происходит по мере необходимости, чтобы разрешить результаты для
SHOW VARIABLES
и
SHOW STATUS
, которые будут
оттянуты из тех таблиц, в зависимости от установки переменной
show_compatibiliy_56
.
performance_schema_accounts_size
Формат командной строки | --performance_schema_accounts_size=#
| ||
Системная | Имя |
performance_schema_accounts_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autoscaled) | ||
Минимум | -1 (autoscaled) | ||
Максимум | 1048576 |
Число строк в accounts
. Если эта переменная 0, Performance Schema
не поддерживает статистику соединения в
accounts
или информацию о переменных состояния в
status_by_account
.
performance_schema_digests_size
Формат командной строки | --performance_schema_digests_size=#
| ||
Системная | Имя |
performance_schema_digests_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autosized) | ||
Минимум | -1 | ||
Максимум | 1048576 |
Максимальное количество строк в таблице
events_statements_summary_by_digest
.
Если этот максимум превышен таким образом, что обзор не может быть
инструментован, Performance Schema постепенно увеличивает переменную
Performance_schema_digest_lost
.
performance_schema_error_size
Формат командной строки | --performance_schema_error_size |
||
Системная | Имя |
performance_schema_error_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | number of server error codes | ||
Минимум | 0 | ||
Максимум | 1048576 |
Число инструментованных кодов ошибки сервера. Значение по умолчанию: фактическое число кодов ошибки сервера. Хотя значение может быть установлено от 0 до максимума, намеченное использование должно установить его в любое значение по умолчанию (чтобы инструментовать все ошибки) или 0 (чтобы не инструментовать ошибки).
Информация об ошибке соединена в сводных таблицах, см.
раздел 23.9.15.10.
Если происходит ошибка, которая не инструментована, информация для
возникновения соединена к строке NULL
в каждой сводной таблице, то есть, к строке с
ERROR_NUMBER=0
, ERROR_NAME=NULL
и
SQLSTATE=NULL
.
performance_schema_events_stages_history_long_size
Формат командной строки |
--performance_schema_events_stages_history_long_size=# | ||
Системная | Имя |
performance_schema_events_stages_history_long_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autosized) |
Число строк в
events_stages_history_long
.
performance_schema_events_stages_history_size
Формат командной строки | --performance_schema_events_stages_history_size=# | ||
Системная | Имя |
performance_schema_events_stages_history_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autosized) |
Число строк на поток в
events_stages_history
.
performance_schema_events_statements_history_long_size
Формат командной строки | --performance_schema_events_statements_history_long_size=#
| ||
Системная | Имя |
performance_schema_events_statements_history_long_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autosized) |
Число строк в
events_statements_history_long
.
performance_schema_events_statements_history_size
Формат командной строки |
--performance_schema_events_statements_history_size=# | ||
Системная | Имя |
performance_schema_events_statements_history_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autosized) |
Число строк на поток в
events_statements_history
.
performance_schema_events_transactions_history_long_size
Формат командной строки |
--performance_schema_events_transactions_history_long_size=# | ||
Системная | Имя |
erformance_schema_events_transactions_history_long_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autosized) |
Число строк в
events_transactions_history_long
.
performance_schema_events_transactions_history_size
Формат командной строки |
--performance_schema_events_transactions_history_size=# | ||
Системная | Имя |
performance_schema_events_transactions_history_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autosized) |
Число строк на поток в
events_transactions_history
.
performance_schema_events_waits_history_long_size
Формат командной строки |
--performance_schema_events_waits_history_long_size=# | ||
Системная | Имя |
performance_schema_events_waits_history_long_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autosized) |
Число строк в
events_waits_history_long
.
performance_schema_events_waits_history_size
Формат командной строки |
--performance_schema_events_waits_history_size=# | ||
Системная | Имя |
performance_schema_events_waits_history_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autosized) |
Число строк на поток в
events_waits_history
.
performance_schema_hosts_size
Формат командной строки | --performance_schema_hosts_size=#
| ||
Системная | Имя |
performance_schema_hosts_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autoscaled) | ||
Минимум | -1 (autoscaled) | ||
Максимум | 1048576 |
Число строк в hosts
.
Если эта переменная 0, Performance Schema не поддерживает статистику
соединения в hosts
или информацию о переменных состояния в
status_by_host
.
performance_schema_max_cond_classes
Формат командной строки | --performance_schema_max_cond_classes=#
| ||
Системная | Имя |
performance_schema_max_cond_classes | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | 80 |
Максимальное количество инструментованных условий.
performance_schema_max_cond_instances
Формат командной строки | --performance_schema_max_cond_instances=#
| ||
Системная | Имя |
performance_schema_max_cond_instances | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autoscaled) |
Максимальное количество инструментованных объектов условия.
performance_schema_max_digest_length
Формат командной строки | --performance_schema_max_digest_length=#
| ||
Системная | Имя |
performance_schema_max_digest_length | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | 1024 | ||
Минимум | 0 | ||
Максимум | 1048576 |
Максимальное количество байтов, доступных для вычислительных обзоров
(см. раздел 23.7
). Эта переменная походит на
max_digest_length
, но относится только к Performance Schema.
Для получения дополнительной информации см. описание этой переменной в
разделе 6.1.5.
performance_schema_max_file_classes
Формат командной строки | --performance_schema_max_file_classes=#
| ||
Системная | Имя |
performance_schema_max_file_classes | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | 80 |
Максимальное количество инструментов файла.
performance_schema_max_file_handles
Формат командной строки | --performance_schema_max_file_handles=#
| ||
Системная | Имя |
performance_schema_max_file_handles | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | 32768 |
Максимальное количество открытых объектов файла.
Значение
performance_schema_max_file_handles
должно быть больше, чем
значение open_files_limit
:
open_files_limit
затрагивает максимальное количество открытых
дескрипторов, которые сервер может поддержать, а
performance_schema_max_file_handles
указывает, сколько из этих
дескрипторов может быть инструментовано.
performance_schema_max_file_instances
Формат командной строки | --performance_schema_max_file_instances=#
| ||
Системная | Имя |
performance_schema_max_file_instances | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autoscaled) |
Максимальное количество инструментованных объектов файла.
performance_schema_max_index_stat
Формат командной строки | --performance_schema_max_index_stat=#
| ||
Системная | Имя |
performance_schema_max_index_stat | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autosized) |
Максимальное количество индексов, для которых Performance Schema
поддерживает статистику. Если этот максимум превышен, статистика индексов
потеряна, а Performance Schema постепенно увеличивает переменную
Performance_schema_index_stat_lost
.
Значение по умолчанию задано, используя значение
performance_schema_max_table_instances
.
performance_schema_max_memory_classes
Формат командной строки | --performance_schema_max_memory_classes=#
| ||
Системная | Имя |
performance_schema_max_memory_classes | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | 320 |
Максимальное количество инструментов памяти.
performance_schema_max_metadata_locks
Формат командной строки | --performance_schema_max_metadata_locks=#
| ||
Системная | Имя |
performance_schema_max_metadata_locks | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autoscaled) |
Максимальное количество метаданных блокировки инструментов.
Это значение управляет размером таблицы
metadata_locks
.
Если этот максимум превышен таким образом, что блокировка метаданных не может
быть инструментована, Performance Schema постепенно увеличивает
Performance_schema_metadata_lock_lost
.
performance_schema_max_mutex_classes
Формат командной строки | --performance_schema_max_mutex_classes=#
| ||
Системная | Имя |
performance_schema_max_mutex_classes | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | 200 |
Максимальное количество инструментов mutex.
performance_schema_max_mutex_instances
Формат командной строки | --performance_schema_max_mutex_instances=#
| ||
Системная | Имя |
performance_schema_max_mutex_instances | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autoscaled) |
Максимальное количество инструментованных объектов mutex.
performance_schema_max_prepared_statements_instances
Формат командной строки |
--performance_schema_max_prepared_statements_instances=# | ||
Системная | Имя |
performance_schema_max_prepared_statements_instances | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autoscaled) |
Максимальное количество строк в таблице
prepared_statements_instances
. Если этот максимум превышен таким
образом, что готовый запрос не может быть инструментован, Performance Schema
постепенно увеличивает переменную
Performance_schema_prepared_statements_lost
.
Значение по умолчанию этой переменной задано, основываясь на значении
переменной
max_prepared_stmt_count
.
performance_schema_max_rwlock_classes
Формат командной строки | --performance_schema_max_rwlock_classes=#
| ||
Системная | Имя |
performance_schema_max_rwlock_classes | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | 40 | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | 20 |
Максимальное количество rwlock инструментов.
performance_schema_max_program_instances
Формат командной строки |
--performance_schema_max_program_instances=# | ||
Системная | Имя |
performance_schema_max_program_instances | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autoscaled) |
Максимальное количество сохраненных программ, для которых
Performance Schema поддерживает статистику. Если этот максимум превышен,
Performance Schema постепенно увеличивает переменную
Performance_schema_program_lost
.
performance_schema_max_rwlock_instances
Формат командной строки | --performance_schema_max_rwlock_instances=#
| ||
Системная | Имя |
performance_schema_max_rwlock_instances | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autoscaled) |
Максимальное количество инструментованных объектов rwlock.
performance_schema_max_socket_classes
Формат командной строки | --performance_schema_max_socket_classes=#
| ||
Системная | Имя |
performance_schema_max_socket_classes | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | 10 |
Максимальное количество инструментов сокета.
performance_schema_max_socket_instances
Формат командной строки | --performance_schema_max_socket_instances=#
| ||
Системная | Имя |
performance_schema_max_socket_instances | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autoscaled) |
Максимальное количество инструментованных объектов сокета.
performance_schema_max_sql_text_length
Формат командной строки | --performance_schema_max_sql_text_length=#
| ||
Системная | Имя |
performance_schema_max_sql_text_length | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | 1024 | ||
Минимум | 0 | ||
Максимум | 1048576 |
Максимальное количество байтов, используемых, чтобы хранить запросы SQL в
столбце SQL_TEXT
таблиц событий
events_statements_current
,
events_statements_history
и
events_statements_history_long
. Любые байты сверх
performance_schema_max_sql_text_length
отказаны и не появляются в
столбце SQL_TEXT
. Запросы, отличающиеся только после этих
начальных байтов, неразличимы в этом столбце.
Уменьшение значения
performance_schema_max_sql_text_length
уменьшает использование памяти, но заставляет больше запросов становиться
неразличимыми, если они отличаются только в конце. Увеличение значения
увеличивает использование памяти, но разрешает более длинные
запросы, которые отличаются.
performance_schema_max_stage_classes
Формат командной строки | --performance_schema_max_stage_classes=#
| ||
Системная | Имя |
performance_schema_max_stage_classes | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | 150 |
Максимальное количество инструментов этапа.
performance_schema_max_statement_classes
Формат командной строки | --performance_schema_max_statement_classes=# | ||
Системная | Имя |
performance_schema_max_statement_classes | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autosized) |
Максимальное количество инструментов запроса. Значение по умолчанию вычислено в сервере, основываясь на числе команд в протоколе клиент-сервер и числе типов запросов SQL, поддержанных сервером.
Эта переменная не должна быть заменена, если не установить ее в 0, чтобы отключить всю инструментовку запросов и сохранить всю память, связанную с нею. Установка переменной к ненулевым значениям кроме значения по умолчанию не обладает никаким преимуществом, в частности значения, больше чем значение по умолчанию, заставляют больше памяти быть выделенной.
performance_schema_max_statement_stack
Формат командной строки | --performance_schema_max_statement_stack=#
| ||
Системная | Имя |
performance_schema_max_statement_stack | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | 10 |
Максимальная глубина вложенных вызовов сохраненных программ, для которых
Performance Schema поддерживает статистику. Когда этот максимум превышен,
Performance Schema постепенно увеличивает переменную
Performance_schema_nested_statement_lost
для каждой
выполненной сохраненной программы.
performance_schema_max_table_handles
Формат командной строки | --performance_schema_max_table_handles=#
| ||
Системная | Имя |
performance_schema_max_table_handles | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autoscaled) |
Максимальное количество открытых табличных объектов. Это значение
управляет размером таблицы
table_handles
.
Если этот максимум превышен таким образом, что табличный дескриптор не может
быть инструментован, Performance Schema постепенно увеличивает переменную
Performance_schema_table_handles_lost
.
performance_schema_max_table_instances
Формат командной строки | --performance_schema_max_table_instances=#
| ||
Системная | Имя |
performance_schema_max_table_instances | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autoscaled) |
Максимальное количество инструментованных табличных объектов.
performance_schema_max_table_lock_stat
Формат командной строки | --performance_schema_max_table_lock_stat=#
| ||
Системная | Имя |
performance_schema_max_table_lock_stat | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autosized) |
Максимальное количество таблиц, для которых Performance Schema
поддерживает статистику блокировки. Если этот максимум превышен таким
образом, что табличные статистические данные блокировки потеряны,
Performance Schema увеличивает переменную
Performance_schema_table_lock_stat_lost
.
performance_schema_max_thread_classes
Формат командной строки | --performance_schema_max_thread_classes=#
| ||
Системная | Имя |
performance_schema_max_thread_classes | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | 50 |
Максимальное количество инструментов потока.
performance_schema_max_thread_instances
Формат командной строки | --performance_schema_max_thread_instances=#
| ||
Системная | Имя |
performance_schema_max_thread_instances | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autoscaled) |
Максимальное количество инструментованных объектов потока. Значение
управляет размером таблицы threads
. Если этот максимум превышен таким образом, что поток не может
быть инструментован, Performance Schema постепенно увеличивает переменную
Performance_schema_thread_instances_lost
.
Переменная
max_connections
затрагивает, сколько потоков может работать в
сервере.
performance_schema_max_thread_instances
указывает,
сколько из этих рабочих потоков может быть инструментовано.
Таблицы
variables_by_thread
и
status_by_thread
содержат информацию только о потоках переднего
плана. Если не все потоки будут инструментованы Performance Schema,
то эта таблица пропустит некоторые строки. В этом случае переменная состояния
Performance_schema_thread_instances_lost
будет больше, чем ноль.
performance_schema_session_connect_attrs_size
Формат командной строки |
--performance_schema_session_connect_attrs_size=# | ||
Системная | Имя |
performance_schema_session_connect_attrs_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autosized) | ||
Минимум | -1 | ||
Максимум | 1048576 |
Количество предварительно выделенной памяти на поток, чтобы держать
атрибуты соединения. Если совокупный размер данных о признаке соединения,
посланных клиентом, больше чем это количество, Performance Schema
усекает данные о признаке, увеличивая переменную
Performance_schema_session_connect_attrs_lost
и пишет сообщение в журнал ошибок, указывающее, что усечение произошло, если
переменная log_warnings
больше, чем ноль. Атрибут _truncated
также добавлен к
признакам сеанса со значением, указывающим, сколько байтов было потеряно,
если у буфера признаков есть достаточное пространство. Это позволяет
Performance Schema выставить информацию об усечении на соединение в таблицах
атрибутов соединения. Эта информация может быть исследована, не имея
необходимость проверять журнал ошибок.
Значение по умолчанию
performance_schema_session_connect_attrs_size
задано при запуске сервера. Это значение может быть маленьким,
так, если усечение происходит
(
Performance_schema_session_connect_attrs_lost
становится отличным от нуля), Вы можете хотеть установить
performance_schema_session_connect_attrs_size
явно к большему значению.
Хотя максимум разрешенного значения
performance_schema_session_connect_attrs_size
составляет 1 МБ, эффективный максимум составляет 64 КБ, потому что сервер
налагает предел в 64 КБ на совокупный размер данных о признаке соединения.
Если клиент пытается послать больше чем 64 КБ данных о признаке, сервер
отклоняет соединение. Для получения дополнительной информации см.
раздел
23.9.9.
performance_schema_setup_actors_size
Формат командной строки | --performance_schema_setup_actors_size=#
| ||
Системная | Имя |
performance_schema_setup_actors_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autoscaled) |
Число строк в таблице
setup_actors
.
performance_schema_setup_objects_size
Формат командной строки | --performance_schema_setup_objects_size=#
| ||
Системная | Имя |
performance_schema_setup_objects_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип |
integer | |
Значение по умолчанию | -1 (autoscaled) |
Число строк в таблице
setup_objects
.
performance_schema_users_size
Формат командной строки | --performance_schema_users_size=#
| ||
Системная | Имя |
performance_schema_users_size | |
Область действия | Глобальная | ||
Динамическая | Нет | ||
Допустимые значения | Тип | integer | |
Значение по умолчанию | -1 (autoscaled) | ||
Минимум | -1 (autoscaled) | ||
Максимум | 1048576 |
Число строк в таблице users
. Если эта переменная 0, Performance Schema не поддерживает статистику
соединения в users
или информацию о переменных состояния в
status_by_user
.
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_accounts_lost
Сколько раз строка не могла быть добавлена к таблице
accounts
потому,
что она была полна.
Performance_schema_cond_classes_lost
Сколько инструментов условия не могло быть загружено.
Performance_schema_cond_instances_lost
Сколько инструментальных случаев условия не могло быть создано.
Performance_schema_digest_lost
Число случаев обзора, которые не могли быть инструментованы в
events_statements_summary_by_digest
.
Это может быть отличным от нуля, если значение
performance_schema_digests_size
является слишком маленьким.
Performance_schema_file_classes_lost
Сколько инструментов файла не могло быть загружено.
Performance_schema_file_handles_lost
Сколько инструментальных случаев файла не могло быть открыто.
Performance_schema_file_instances_lost
Сколько инструментальных случаев файла не могло быть создано.
Performance_schema_hosts_lost
Сколько раз строка не могла быть добавлена к таблице
hosts
потому, что она была полна.
Performance_schema_index_stat_lost
Число индексов, для которых были потеряны статистические данные. Это может
быть отличным от нуля, если значение
performance_schema_max_index_stat
является слишком маленьким.
Performance_schema_locker_lost
Сколько событий потеряны или не зарегистрированы из-за следующих условий:
События являются рекурсивными.
События, зарегистрированные Performance Schema, не являются рекурсивными, таким образом, эта переменная должна всегда быть 0.
Performance_schema_memory_classes_lost
Сколько раз инструмент памяти не мог быть загружен.
Performance_schema_metadata_lock_lost
Число блокировок метаданных, которые не могли быть инструментованы в
metadata_locks
.
Это может быть отличным от нуля, если значение
performance_schema_max_metadata_locks
является слишком маленьким.
Performance_schema_mutex_classes_lost
Сколько инструментов mutex не могло быть загружено.
Performance_schema_mutex_instances_lost
Сколько инструментальных случаев mutex не могло быть создано.
Performance_schema_nested_statement_lost
Число сохраненных запросов программы, для которых были потеряны
статистические данные. Это может быть отличным от нуля, если значение
performance_schema_max_statement_stack
является слишком маленьким.
Performance_schema_prepared_statements_lost
Число готовых запросов, которые не могли быть инструментованы в таблице
prepared_statements_instances
.
Это может быть отличным от нуля, если значение
performance_schema_max_prepared_statements_instances
является слишком маленьким.
Performance_schema_program_lost
Число сохраненных программ, для которых были потеряны статистические
данные. Это может быть отличным от нуля, если значение
performance_schema_max_program_instances
является слишком маленьким.
Performance_schema_rwlock_classes_lost
Сколько rwlock инструментов не могло быть загружено.
Performance_schema_rwlock_instances_lost
Сколько rwlock инструментальных случаев не могло быть создано.
Performance_schema_session_connect_attrs_longest_seen
В дополнение к проверке размера атрибутов соединения, выполненной
Performance Schema по значению системной переменной
performance_schema_session_connect_attrs_size
,
сервер выполняет предварительную проверку, налагая предел 64 КБ на совокупный
размер данных о признаке соединения, который примет. Если клиент пытается
послать больше, чем 64 КБ данных о признаке, сервер отклоняет соединение.
Иначе, сервер полагает, что признак допустимый, и отслеживает размер самого
длинного буфера в переменной
Performance_schema_session_connect_attrs_longest_seen
.
Если это значение больше, чем
performance_schema_session_connect_attrs_size
, DBA
может хотеть увеличить последнее значение или заняться расследованиями, какие
клиенты посылают большое количество данных о признаке.
Performance_schema_session_connect_attrs_lost
Число соединений, для которых произошло усечение признака соединения. Для
данного соединения, если клиент посылает пары ключа/значения признака
соединения, для которых совокупный размер больше, чем разрешенное значение
performance_schema_session_connect_attrs_size
, Performance
Schema усекает данные о признаке и увеличивает
Performance_schema_session_connect_attrs_lost
.
Если это значение является отличным от нуля, Вы можете хотеть установить
performance_schema_session_connect_attrs_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_max_table_handles
является слишком маленьким.
Performance_schema_table_instances_lost
Сколько табличных инструментальных случаев не могло быть создано.
Performance_schema_table_lock_stat_lost
Число таблиц, для которых были потеряны статистические данные блокировки.
Это может быть отличным от нуля, если значение
performance_schema_max_table_lock_stat
является слишком маленьким.
Performance_schema_thread_classes_lost
Сколько инструментов потока не могло быть загружено.
Performance_schema_thread_instances_lost
Число случаев потока, которые не могли быть инструментованы в
threads
.
Это может быть отличным от нуля, если значение
performance_schema_max_thread_instances
является слишком маленьким.
Performance_schema_users_lost
Сколько раз строка не могла быть добавлена к
users
, потому что
она была полна.
Для информации об использовании этих переменных, чтобы проверить статус Performance Schema, см. раздел 23.5.
Performance Schema использует эту модель распределения памяти:
Может выделить память при запуске сервера.
Результат состоит в том, чтобы ослабить ограничения памяти так, чтобы Performance Schema могла использоваться с меньшим количеством конфигурации, и уменьшить расход памяти так, чтобы потребление масштабировалось с загрузкой сервера. Используемая память зависит от загрузки, фактически замеченной, не оцененной загрузки или явно сконфигурированный.
Несколько измеряющих параметров Performance Schema автомасштабируются и не должны быть сконфигурированы явно, если Вы не хотите установить явный предел на распределение памяти:
performance_schema_accounts_size performance_schema_hosts_size performance_schema_max_cond_instances performance_schema_max_file_instances performance_schema_max_index_stat performance_schema_max_metadata_locks performance_schema_max_mutex_instances performance_schema_max_prepared_statements_instances performance_schema_max_program_instances performance_schema_max_rwlock_instances performance_schema_max_socket_instances performance_schema_max_table_handles performance_schema_max_table_instances performance_schema_max_table_lock_stat performance_schema_max_thread_instances performance_schema_users_size
Для автомасштабируемого параметра конфигурация работает так:
С набором значений -1 (по умолчанию), автомасштабируется параметр:
Соответствующий внутренний буфер пуст первоначально, и никакая память не выделена.
С набором значений 0:
Соответствующий внутренний буфер пуст первоначально, и никакая память не выделена.
С набором значений N
> 0:
Соответствующий внутренний буфер пуст первоначально, и никакая память не выделена.
N
.N
,
больше памяти не выделено. Данные, собранные Performance Schema
для этого буфера, потеряны, и любой соответствующий счетчик
потерь постепенно увеличен.Чтобы видеть, сколько памяти использует Performance Schema,
проверьте инструменты, разработанные с этой целью. Performance Schema
выделяет память внутренне и связывает каждый буфер со специализированным
инструментом так, чтобы потребление памяти могло быть прослежено к отдельным
буферам. Инструменты с приставкой memory/performance_schema/
покажут, сколько памяти выделено для этих внутренних буферов. Буферы
глобальны для сервера, таким образом, инструменты выведены на экран только в
таблице
memory_summary_global_by_event_name
, а не в других таблицах
memory_summary_by_
.xxx
_by_event_name
Этот запрос показывает информацию, связанную с инструментами памяти:
SELECT * FROM memory_summary_global_by_event_name WHERE EVENT_NAME LIKE 'memory/performance_schema/%';
Удаление плагина с UNINSTALL
PLUGIN
не затрагивает информацию, уже собранную для кода в этом
плагине. Время на выполнение кода, в то время как плагин был загружен, все
еще учтено, даже если плагин позже выгружен. Связанная информация о событии,
включая совокупную информацию, остается читаемой в таблицах базы данных
performance_schema
. Для дополнительной информации об эффекте
установки и удаления плагина см.
раздел 23.5.
Конструктор плагина, который инструментует код, должен зарегистрировать его характеристики инструментовки, чтобы позволить тем, кто загружает плагин, составлять его требования. Например, имеющий отношение к третьей стороне механизм хранения должен включать в документацию, в каком количестве памяти механизм нуждается для mutex и других инструментов.
Performance Schema инструмент, чтобы помочь DBA сделать работу, проводя реальные измерения вместо примерных. Этот раздел, демонстрирует некоторые способы использовать Performance Schema с этой целью. Обсуждение здесь полагается на использование фильтрации событий, которая описана в разделе 23.2.3.2.
Следующий пример обеспечивает одну методологию, которую Вы можете использовать, чтобы проанализировать повторимую проблему, такую как исследование исполнительного узкого места. Чтобы начать, у Вас должен быть повторимый случай использования, где работу считают слишком медленной и нуждающейся в оптимизации, и Вы должны включить всю инструментовку (никакой предварительной фильтрации вообще).
Выполните случай использования.
При каждой итерации, вывод Performance Schema, особенно таблица
events_waits_history_long
будет содержать всё меньше и меньше шума, вызванным незначащими
инструментами, а поскольку у этой таблицы есть фиксированный размер, она
будет содержать все больше данных, относящихся к анализу проблемы.
При каждой итерации исследование должно вести ближе и ближе к первопричине проблемы, поскольку соотношение сигнал/шум улучшится, делая легче анализ.
Настройте параметры сервера (размеры кэша, памяти и т.д.).
Начните снова с шага 1, чтобы видеть эффекты изменений.
Столбцы mutex_instances.LOCKED_BY_THREAD_ID
и
rwlock_instances.WRITE_LOCKED_BY_THREAD_ID
чрезвычайно важны для
исследования исполнительных узких мест или тупиков. Это сделано возможным
инструментовкой Performance Schema следующим образом:
Предположите, что поток 1 застревает, ожидая mutex.
SELECT * FROM events_waits_current
WHERE THREAD_ID = thread_1
;
Скажите, что результат запроса идентифицирует, что поток ждет mutex A,
найденный в events_waits_current.OBJECT_INSTANCE_BEGIN
.
SELECT * FROM mutex_instances
WHERE OBJECT_INSTANCE_BEGIN = mutex_A
;
Скажите, что результат запроса идентифицирует, что это поток 2, который
держит mutex A, как найдено в
mutex_instances.LOCKED_BY_THREAD_ID
.
SELECT * FROM events_waits_current
WHERE THREAD_ID = thread_2
;
Следующий пример демонстрирует, как использовать события запросов
Performance Schema и события этапа, чтобы получить данные, сопоставимые с
профилированием информации, предоставленной
SHOW PROFILES
и
SHOW PROFILE
.
Таблица setup_actors
может использоваться, чтобы ограничить набор исторических событий узлом,
пользователем или учетной записью, чтобы уменьшить время выполнения
и объем данных, собранный в таблицах истории. Первый шаг примера показывает,
как ограничить набор исторических событий определенному пользователю.
Performance Schema выводит на экран информацию о таймере событий в
пикосекундах, чтобы нормализовать данные о синхронизации к стандартному
модулю. В следующем примере TIMER_WAIT
разделены на
1000000000000, чтобы показать данные в модулях секунд. Значения являются
также усеченными к 6 десятичным разрядам, чтобы вывести на экран данные в том
же самом формате, как SHOW PROFILES
и SHOW PROFILE
.
Ограничьте набор исторических событий пользователю,
который выполняет запрос. По умолчанию
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 | +-----------+-----------+------+---------+---------+
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/%';
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_%';
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 | +--------+------------+------------+-----------+--------+------------+
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 | +----------+----------+--------------------------------------------------------+
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 | +--------------------------------+----------+
INFORMATION_SCHEMA
имеет таблицы, которые содержат информацию
о переменных состояния (см. разделы
22.10 и 22.9). Performance Schema
также содержит таблицы переменных системы и состояния (см. разделы
23.9.13 и
23.9.14).
Таблицы Performance Schema предназначены, чтобы заменить
INFORMATION_SCHEMA
, которые устарели с MySQL 5.7.6 и
будут удалены в будущем выпуске MySQL.
Этот раздел описывает намеченный миграционный путь с
INFORMATION_SCHEMA
к соответствующим таблицам Performance
Schema. Разработчики приложений должны использовать эту информацию в качестве
руководства относительно изменений, требуемых, чтобы получить доступ к
системе и переменным состояния в MySQL.
MySQL 5.6
В MySQL 5.6 информация о переменных состояния доступна
через команду SHOW
:
SHOW VARIABLES SHOW STATUS
И через таблицы INFORMATION_SCHEMA
:
INFORMATION_SCHEMA.GLOBAL_VARIABLES INFORMATION_SCHEMA.SESSION_VARIABLES INFORMATION_SCHEMA.GLOBAL_STATUS INFORMATION_SCHEMA.SESSION_STATUS
MySQL 5.7
С MySQL 5.7.6 Performance Schema включает эти таблицы как новые источники информации о переменных состояния:
performance_schema.global_variables performance_schema.session_variables performance_schema.variables_by_thread performance_schema.global_status performance_schema.session_status performance_schema.status_by_thread performance_schema.status_by_account performance_schema.status_by_host performance_schema.status_by_user
MySQL 5.7.6 также добавляет системную переменную
show_compatibility_56
, чтобы управлять, как сервер делает доступной
информацию о переменных состояния.
Когда
show_compatibility_56
ON
, совместимость с MySQL 5.6
включена. Более старая система и источники переменных состояния
(запросы SHOW
, таблицы INFORMATION_SCHEMA
)
доступны с семантикой, идентичной MySQL 5.6. Приложения должны работать без
изменений кода и должен видеть те же самые имена переменных и значения, как в
MySQL 5.6. Предупреждения происходят при этих обстоятельствах:
Предупреждение поднято при выборе из
таблиц INFORMATION_SCHEMA
.
Когда
show_compatibility_56
OFF
,
совместимость с MySQL 5.6 отключена и несколько результатов изменены.
Приложения должны быть пересмотрены следующим образом, чтобы
работать должным образом:
Выбор из таблицы INFORMATION_SCHEMA
производит ошибку. Приложения с доступом к
INFORMATION_SCHEMA
должны быть пересмотрены, чтобы использовать
соответствующие таблицы Performance Schema.
До MySQL 5.7.9 выбор из INFORMATION_SCHEMA
производит пустой набор результатов плюс предупреждение об устаревании.
Это не было достаточным уведомлением, чтобы сигнализировать о потребности
мигрировать к соответствующей системе Performance Schema, если
show_compatibility_56=OFF
. Производство ошибки в MySQL 5.7.9 и
выше делает более очевидным, что приложение работает при условиях, которые
требуют модификации, так же как где проблема заключается.
SHOW
произведен, используя основные таблицы
Performance Schema. Приложения, написанные, чтобы использовать эти запросы,
могут все еще использовать их.Slave_xxx
становятся недоступными через SHOW STATUS
:
Slave_heartbeat_period Slave_last_heartbeat Slave_received_heartbeats Slave_retried_transactions Slave_running
Приложения, которые используют эти переменные состояния, должны быть пересмотрены, чтобы получить эту информацию, используя связанные с репликацией таблицы Performance Schema.
Миграция и привилегии
Первоначально, с введением Performance Schema в MySQL 5.7.6, доступ к тем
таблицам требовал привилегии SELECT
, так же, как для других таблиц Performance Schema.
Однако, у этого было последствие, когда
show_compatibility_56=OFF
,
SHOW VARIABLES
и
SHOW STATUS
также потребовали
привилегию SELECT
:
с отключенной совместимостью вывод для тех запросов, был взят из таблиц
Performance Schema
global_variables
,
session_variables
,
global_status
и
session_status
.
Эти таблицы Performance Schema доступны без привилегии
SELECT
. Следовательно,
SHOW VARIABLES
и
SHOW STATUS
не требуют
привилегий на основных таблицах Performance Schema, из которых их вывод
произведен, когда
show_compatibility_56=OFF
.
Вне MySQL 5.7
В будущем выпуске MySQL переменные таблицы INFORMATION_SCHEMA
и переменная
show_compatibility_56
будут удалены, и вывод SHOW
всегда будет основан на основных таблицах Performance Schema.
Приложения, которые были пересмотрены, чтобы работать в MySQL 5.7, когда
show_compatibility_56=OFF
, должны работать без дальнейших
изменений, за исключением того, что не будет возможно проверить или
установить
show_compatibility_56
потому, что это не будет существовать.