Глава 23. MySQL Performance Schema
MySQL Performance Schema особенность контроля выполнения MySQL Server
на низком уровне. У Performance Schema есть эти характеристики:
Performance Schema обеспечивает способ осмотреть внутреннее
выполнение сервера во времени выполнения. Это осуществлено, используя
механизм хранения PERFORMANCE_SCHEMA и
базу данных performance_schema. Performance Schema
сосредотачивается прежде всего на характеристиках. Это отличается от
INFORMATION_SCHEMA, которая служит для просмотра метаданных.
- Performance Schema следит за развитием событий сервера.
Событие является чем-либо, что сервер делает, что
занимает время и было инструментовано так, чтобы информация синхронизации
могла быть собрана. Вообще, случаем мог быть вызов функции, ожидание
операционной системы, этапа выполнения запроса SQL, такого как парсинг или
сортировка, всего запроса или группы запросов. Набор событий обеспечивает
доступ к информации о требованиях синхронизации файла и табличного
ввода/вывода, табличные блокировки и т.д. для сервера и для
нескольких механизмов хранения.
- События Performance Schema отличны от событий, записанных в двоичный
журнал сервера (которые описывают модификации данных) и событий Event
Scheduler (которые являются типом сохраненной программы).
- События Performance Schema являются определенными для приведенного
примера MySQL Server. Таблицы Performance Schema считаются локальными для
сервера, и изменения в них не копируются в двоичный журнал.
- Текущие события доступны, так же как истории событий и резюме.
Это позволяет Вам определить, сколько инструментованных действий было
выполнено и сколько времени они заняли. Информация о событии доступна, чтобы
показать действия определенных потоков или деятельность, связанную с особыми
объектами, такими как mutex или файл.
- Механизм хранения
PERFORMANCE_SCHEMA
собирает данные событий, используя точки инструментовки
в исходном коде сервера.
- Собранные события сохранены в таблицах в базе данных
performance_schema. Эти таблицы могут быть запрошены, используя
SELECT как другие таблицы.
- Конфигурация Performance Schema может быть изменена динамически, обновляя
таблицы в базе данных
performance_schema
через запросы SQL. Конфигурация немедленно изменяет сбор данных.
- Таблицы в базе данных
performance_schema это
представления или временные таблицы, которые не используют постоянного
хранения на диске.
- Контроль доступен на всех платформах, поддержанных MySQL.
Некоторые ограничения могут применяться: типы таймеров могут изменяться
для платформы. Инструменты, которые относятся к механизмам хранения, не могут
быть осуществлены для всех механизмов хранения. Инструментовка каждого
имеющего отношение к третьей стороне механизма ответственность автора
механизма. См. также
раздел C.8.
- Сбор данных осуществлен, изменяя исходный код сервера, чтобы добавить
инструментовку. Нет никаких отдельных потоков, связанных с Performance
Schema, в отличие от других особенностей, таких как репликация
или Event Scheduler.
Performance Schema предназначена, чтобы обеспечить доступ к полезной
информации о выполнении сервера, оказывая минимальное влияние на работу
сервера. Выполнение следует за этими целями проекта:
Активирование Performance Schema не вызывает изменений в поведении
сервера. Например, это не вызывает поток, намечающий измениться, и это не
меняет план выполнения запроса (как показано
EXPLAIN). - Контроль сервера происходит непрерывно и незаметно с очень малыми
издержками. Активирование Performance Schema
не делает сервер непригодным.
- Анализатор неизменен. Нет никаких новых ключевых слов или запросов.
- Выполнение сервера обычно работает нормально, даже если
Performance Schema терпит неудачу внутренне.
- Когда есть выбор между выполнением обработки во время набора событий
первоначально или во время извлечения событий позже, приоритет дан созданию
набора быстрее. Это потому, что набор является процессом, тогда как
извлечение происходит по требованию и могло бы не происходить вообще.
- Большинство таблиц Performance Schema имеет индекс, который предоставляет
доступ к планам выполнения, кроме полного сканирования таблицы. Для получения
дополнительной информации см.
раздел 9.2.5.
- Легко добавить новые пункты инструментовки.
- Если выполнение инструментовки изменится, то ранее инструментованный код
продолжит работать. Это приносит пользу разработчикам, имеющим отношение к
плагинам, потому что не надо обновлять каждый плагин, чтобы остаться
синхронизированным с последними изменениями Performance Schema.
MySQL sys schema ряд объектов, который обеспечивает удобный
доступ к данным, собранным Performance Schema. sys schema
установлена по умолчанию. Для инструкций см. раздел 24.
23.1.
Быстрый запуск Performance Schema
Этот раздел кратко начинает Performance Schema с примеров, которые
показывают, как использовать это. Для дополнительных примеров см.
раздел 23.16.
Чтобы Performance Schema была доступна, она должна быть сконфигурирована,
когда MySQL был создан. Вы можете проверить обстоит ли дело так, проверяя
вывод сервера. Если Performance Schema доступна, то вывод упомянет несколько
переменных с именами, которые начинаются с performance_schema:
shell> mysqld --verbose --help
...
--performance_schema
Enable the performance schema.
--performance_schema_events_waits_history_long_size=#
Number of rows in events_waits_history_long.
...
Если такие переменные не появляются в выводе, Ваш сервер не был создан,
чтобы поддерживать Performance Schema. В этом случае см.
раздел 23.2.
Предполагая, что Performance Schema доступна, она включена по умолчанию.
Чтобы включить или отключить это явно, запустите сервер с соответствующим
значением переменной
performance_schema. Например, используйте эти строки в Вашем
файле my.cnf:
[mysqld]
performance_schema=ON
Когда сервер запускается, он видит
performance_schema
и попытается инициализировать Performance Schema.
Чтобы проверить успешную инициализацию, используйте этот запрос:
mysql> SHOW VARIABLES LIKE 'performance_schema';
+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| performance_schema | ON |
+--------------------+-------+
Значение ON указывает, что Performance Schema
инициализированная успешно и готова к употреблению. Значение OFF
указывает, что некоторая ошибка произошла. Проверьте журнал ошибок сервера на
информацию о том, что пошло не так, как надо.
Performance Schema осуществлена как механизм хранения. Если этот механизм
доступен (это Вы должны были уже проверить ранее), Вы должны видеть, что он
перечислен со значением YES столбца SUPPORT таблицы
INFORMATION_SCHEMA.ENGINES
или вывода SHOW ENGINES:
mysql> SELECT * FROM INFORMATION_SCHEMA.ENGINES
WHERE ENGINE='PERFORMANCE_SCHEMA'\G
*************************** 1. row ***************************
ENGINE: PERFORMANCE_SCHEMA
SUPPORT: YES
COMMENT: Performance Schema
TRANSACTIONS: NO
XA: NO
SAVEPOINTS: NO
mysql> SHOW ENGINES\G
...
Engine: PERFORMANCE_SCHEMA
Support: YES
Comment: Performance Schema
Transactions: NO
XA: NO
Savepoints: NO
...
Механизм хранения PERFORMANCE_SCHEMA
воздействует на таблицы в базе данных performance_schema.
Вы можете сделать базу данных performance_schema базой данных по
умолчанию так, чтобы ссылки на ее таблицы не были квалифицированы с
именем базы данных:
mysql> USE performance_schema;
Много примеров в этой главе принимают performance_schema
как базу данных по умолчанию.
Таблицы Performance Schema сохранены в базе данных
performance_schema. Информация о структуре этой базы данных и ее
таблиц может быть получена как для любой другой базы данных, выбирая из
INFORMATION_SCHEMA или при использовании
SHOW. Например, используйте любой из
этих запросов, чтобы видеть, какие таблицы Performance Schema существуют:
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'performance_schema';
+------------------------------------------------+
| TABLE_NAME |
+------------------------------------------------+
| accounts |
| cond_instances |
...
| events_stages_current |
| events_stages_history |
| events_stages_history_long |
| events_stages_summary_by_account_by_event_name |
| events_stages_summary_by_host_by_event_name |
| events_stages_summary_by_thread_by_event_name |
| events_stages_summary_by_user_by_event_name |
| events_stages_summary_global_by_event_name |
| events_statements_current |
| events_statements_history |
| events_statements_history_long |
...
| file_instances |
| file_summary_by_event_name |
| file_summary_by_instance |
| host_cache |
| hosts |
| memory_summary_by_account_by_event_name |
| memory_summary_by_host_by_event_name |
| memory_summary_by_thread_by_event_name |
| memory_summary_by_user_by_event_name |
| memory_summary_global_by_event_name |
| metadata_locks |
| mutex_instances |
| objects_summary_global_by_type |
| performance_timers |
| replication_connection_configuration |
| replication_connection_status |
| replication_applier_configuration |
| replication_applier_status |
| replication_applier_status_by_coordinator |
| replication_applier_status_by_worker |
| rwlock_instances |
| session_account_connect_attrs |
| session_connect_attrs |
| setup_actors |
| setup_consumers |
| setup_instruments |
| setup_objects |
| setup_timers |
| socket_instances |
| socket_summary_by_event_name |
| socket_summary_by_instance |
| table_handles |
| table_io_waits_summary_by_index_usage |
| table_io_waits_summary_by_table |
| table_lock_waits_summary_by_table |
| threads |
| users |
+------------------------------------------------+
mysql> SHOW TABLES FROM performance_schema;
+------------------------------------------------------+
| Tables_in_performance_schema |
+------------------------------------------------------+
| accounts |
| cond_instances |
| events_stages_current |
| events_stages_history |
| events_stages_history_long |
...
Число таблиц Performance Schema увеличится в течение долгого времени как
выполнение дополнительных инструментов.
Название базы данных performance_schema в нижнем регистре,
как и названия таблиц в ее пределах. Запросы должны определить
имена в нижнем регистре.
Чтобы видеть структуру отдельных таблиц, надо использовать
SHOW CREATE TABLE:
mysql> SHOW CREATE TABLE setup_timers\G
*************************** 1. row ***************************
Table: setup_timers
Create Table: CREATE TABLE `setup_timers` (
`NAME` varchar(64) NOT NULL,
`TIMER_NAME` enum('CYCLE','NANOSECOND','MICROSECOND','MILLISECOND','TICK')
NOT NULL) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8
Структура таблицы также доступна, выбирая из таких таблиц, как
INFORMATION_SCHEMA.COLUMNS
или при использовании запросов SHOW COLUMNS.
Таблицы в performance_schema могут быть сгруппированы
согласно типу информации в них: текущие события, истории событий и резюме,
экземпляры объектов и информацию конфигурации. Следующие примеры иллюстрируют
несколько вариантов использования для этих таблиц. Для получения дальнейшей
информации о таблицах в каждой группе см.
раздел 23.9.
Первоначально, не все инструменты и потребители включены, таким образом,
performance schema не собирает все события. Чтобы включить всех их и включить
синхронизацию событий, выполните два запроса (количество строк может
отличаться в зависимости от версии MySQL):
mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES';
Query OK, 560 rows affected (0.04 sec)
mysql> UPDATE setup_consumers SET ENABLED = 'YES';
Query OK, 10 rows affected (0.00 sec)
Чтобы видеть, что сервер делает в настоящее время, исследуйте таблицу
events_waits_current
. Это содержит одну строку на поток, показывая новое следившее за
развитием событие каждого потока:
mysql> SELECT * FROM events_waits_current\G
*************************** 1. row ***************************
THREAD_ID: 0
EVENT_ID: 5523
EVENT_NAME: wait/synch/mutex/mysys/THR_LOCK::mutex
SOURCE: thr_lock.c:525
TIMER_START: 201660494489586
TIMER_END: 201660494576112
TIMER_WAIT: 86526
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 142270668
NESTING_EVENT_ID: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: 0
...
Этот случай указывает, что поток 0 ждал 86526 пикосекунд, чтобы приобрести
блокировку на THR_LOCK::mutex, mutex в подсистеме
mysys. Первые несколько столбцов
предоставляют следующую информацию:
Таблицы истории содержат тот же самый вид строк как таблица текущих
событий, но имеют больше строк и показывают то, что сервер делал. Таблицы
events_waits_history
и
events_waits_history_long содержат самые свежие 10 событий на
поток и новые 10000 событий, соответственно. Например, чтобы увидеть
информацию для недавних событий, произведенных потоком 13, сделайте это:
mysql> SELECT EVENT_ID, EVENT_NAME, TIMER_WAIT
FROM events_waits_history WHERE THREAD_ID = 13
ORDER BY EVENT_ID;
+----------+-----------------------------------------+------------+
| EVENT_ID | EVENT_NAME | TIMER_WAIT |
+----------+-----------------------------------------+------------+
| 86 | wait/synch/mutex/mysys/THR_LOCK::mutex | 686322 |
| 87 | wait/synch/mutex/mysys/THR_LOCK_malloc | 320535 |
| 88 | wait/synch/mutex/mysys/THR_LOCK_malloc | 339390 |
| 89 | wait/synch/mutex/mysys/THR_LOCK_malloc | 377100 |
| 90 | wait/synch/mutex/sql/LOCK_plugin | 614673 |
| 91 | wait/synch/mutex/sql/LOCK_open | 659925 |
| 92 | wait/synch/mutex/sql/THD::LOCK_thd_data | 494001 |
| 93 | wait/synch/mutex/mysys/THR_LOCK_malloc | 222489 |
| 94 | wait/synch/mutex/mysys/THR_LOCK_malloc | 214947 |
| 95 | wait/synch/mutex/mysys/LOCK_alarm | 312993 |
+----------+-----------------------------------------+------------+
Поскольку новые события добавлены к таблице истории, от более старых
событий отказываются, если таблица полна.
Сводные таблицы предоставляют соединенную информацию для всех событий в
течение долгого времени. Таблицы в этой группе суммируют данные событий
по-разному. Чтобы видеть, какие инструменты были запущены большинство раз или
заняли больше времени, сортируют таблицу
events_waits_summary_global_by_event_name по столбцу
COUNT_STAR или SUM_TIMER_WAIT, которые
соответствуют COUNT(*) или SUM(TIMER_WAIT),
соответственно, вычисленным по всем событиям:
mysql> SELECT EVENT_NAME, COUNT_STAR
FROM events_waits_summary_global_by_event_name
ORDER BY COUNT_STAR DESC LIMIT 10;
+---------------------------------------------------+------------+
| EVENT_NAME | COUNT_STAR |
+---------------------------------------------------+------------+
| wait/synch/mutex/mysys/THR_LOCK_malloc | 6419 |
| wait/io/file/sql/FRM | 452 |
| wait/synch/mutex/sql/LOCK_plugin | 337 |
| wait/synch/mutex/mysys/THR_LOCK_open | 187 |
| wait/synch/mutex/mysys/LOCK_alarm | 147 |
| wait/synch/mutex/sql/THD::LOCK_thd_data | 115 |
| wait/io/file/myisam/kfile | 102 |
| wait/synch/mutex/sql/LOCK_global_system_variables | 89 |
| wait/synch/mutex/mysys/THR_LOCK::mutex | 89 |
| wait/synch/mutex/sql/LOCK_open | 88 |
+---------------------------------------------------+------------+
mysql> SELECT EVENT_NAME, SUM_TIMER_WAIT
FROM events_waits_summary_global_by_event_name
ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;
+----------------------------------------+----------------+
| EVENT_NAME | SUM_TIMER_WAIT |
+----------------------------------------+----------------+
| wait/io/file/sql/MYSQL_LOG | 1599816582 |
| wait/synch/mutex/mysys/THR_LOCK_malloc | 1530083250 |
| wait/io/file/sql/binlog_index | 1385291934 |
| wait/io/file/sql/FRM | 1292823243 |
| wait/io/file/myisam/kfile | 411193611 |
| wait/io/file/myisam/dfile | 322401645 |
| wait/synch/mutex/mysys/LOCK_alarm | 145126935 |
| wait/io/file/sql/casetest | 104324715 |
| wait/synch/mutex/sql/LOCK_plugin | 86027823 |
| wait/io/file/sql/pid | 72591750 |
+----------------------------------------+----------------+
Эти результаты показывают, что THR_LOCK_malloc
востребована с точки зрения того, как часто используется и количества
времени, которое потоки ждут, пытаясь приобрести это.
THR_LOCK_malloc mutex используется только в отладке.
Таблицы документируют, какие типы объектов инструментованы.
Инструментованный объект, когда используется сервером, производит случай. Эти
таблицы обеспечивают имена событий и примечания или информацию о статусе.
Например, таблица
file_instances приводит случаи инструментов для операций
ввода/вывода файла и их связанных файлов:
mysql> SELECT * FROM file_instances\G
*************************** 1. row ***************************
FILE_NAME: /opt/mysql-log/60500/binlog.000007
EVENT_NAME: wait/io/file/sql/binlog
OPEN_COUNT: 0
*************************** 2. row ***************************
FILE_NAME: /opt/mysql/60500/data/mysql/tables_priv.MYI
EVENT_NAME: wait/io/file/myisam/kfile
OPEN_COUNT: 1
*************************** 3. row ***************************
FILE_NAME: /opt/mysql/60500/data/mysql/columns_priv.MYI
EVENT_NAME: wait/io/file/myisam/kfile
OPEN_COUNT: 1
...
Таблицы установки используются, чтобы сконфигурировать и вывести на экран
контролирующие характеристики. Например, чтобы видеть, какие таймеры
событий выбраны, запросите таблицы
setup_timers:
mysql> SELECT * FROM setup_timers;
+-------------+-------------+
| NAME | TIMER_NAME |
+-------------+-------------+
| idle | MICROSECOND |
| wait | CYCLE |
| stage | NANOSECOND |
| statement | NANOSECOND |
| transaction | NANOSECOND |
+-------------+-------------+
setup_instruments
перечисляет набор инструментов, для которых события могут быть
собраны и показывает, которые из них включены:
mysql> SELECT * FROM setup_instruments;
+---------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+---------------------------------------------------+---------+-------+
...
| wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES |
| wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES |
| wait/synch/mutex/sql/LOCK_lock_db | YES | YES |
| wait/synch/mutex/sql/LOCK_manager | YES | YES |
...
| wait/synch/rwlock/sql/LOCK_grant | YES | YES |
| wait/synch/rwlock/sql/LOGGER::LOCK_logger | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_connect | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_slave | YES | YES |
...
| wait/io/file/sql/binlog | YES | YES |
| wait/io/file/sql/binlog_index | YES | YES |
| wait/io/file/sql/casetest | YES | YES |
| wait/io/file/sql/dbopt | YES | YES |
...
Чтобы понять, как интерпретировать инструментальные имена см.
раздел 23.4.
Чтобы управлять тем, собраны ли события для инструмента, устанавливайте
значение ENABLED в YES или NO:
mysql> UPDATE setup_instruments SET ENABLED = 'NO'
WHERE NAME = 'wait/synch/mutex/sql/LOCK_mysql_create_db';
Performance Schema использует собранные события, чтобы обновить таблицы в
performance_schema, которые действуют как
потребители информации о событии. Таблица
setup_consumers
приводит доступных потребителей и которые включены:
mysql> SELECT * FROM setup_consumers;
+----------------------------------+---------+
| NAME | ENABLED |
+----------------------------------+---------+
| events_stages_current | NO |
| events_stages_history | NO |
| events_stages_history_long | NO |
| events_statements_current | YES |
| events_statements_history | YES |
| events_statements_history_long | NO |
| events_transactions_current | NO |
| events_transactions_history | NO |
| events_transactions_history_long | NO |
| events_waits_current | NO |
| events_waits_history | NO |
| events_waits_history_long | NO |
| global_instrumentation | YES |
| thread_instrumentation | YES |
| statements_digest | YES |
+----------------------------------+---------+
Чтобы управлять тем, поддерживает ли Performance Schema как место
назначения для информации о событии, устанавливайте ENABLED.
Для получения дополнительной информации о таблицах установки и как
использовать их, чтобы управлять набором событий см.
раздел 23.2.3.2.
Есть некоторые разные таблицы, которые не попадают ни в одну из
предыдущих групп. Например,
performance_timers
перечисляет доступные таймеры событий и их характеристики. Для
информации о таймерах см.
раздел 23.2.3.1.
23.2.
Конфигурация Performance Schema
Чтобы использовать MySQL Performance Schema,
эти соображения конфигурации применяются:
Performance Schema должна быть сконфигурирована в ходе сборки
MySQL Server, чтобы она была доступна. Performance Schema включена в двоичные
дистрибутивы MySQL. Если Вы создаете пакет из исходных текстов, Вы должны
гарантировать, что он сконфигурирован как описано в
разделе 23.2.1
. - Performance Schema должна быть позволена при запуске сервера, чтобы
позволить набору событий произойти. Опции Performance Schema могут быть
активированы при запуске сервера или во времея выполнения, чтобы управлять,
какие типы событий происходят. См. разделы
23.2.2,
23.2.3 и
23.2.3.2.
23.2.1.
Создание конфигурации Performance Schema
Если Вы создаете MySQL из исходных текстов, включите
Performance Schema запуском CMake с опцией
WITH_PERFSCHEMA_STORAGE_ENGINE:
shell> cmake . -DWITH_PERFSCHEMA_STORAGE_ENGINE=1
Конфигурирование MySQL с опцией
-DWITHOUT_PERFSCHEMA_STORAGE_ENGINE=1 запрещает включение
Performance Schema, так что, если Вы хотите включить, не используйте эту
опцию. См. раздел 2.8.4
.
Также возможно включить Performance Schema, но исключить определенные
части инструментовки. Например, чтобы включить Performance Schema, но
исключить инструментовку этапов и запросов, сделайте это:
shell> cmake . -DWITH_PERFSCHEMA_STORAGE_ENGINE=1 \
-DDISABLE_PSI_STAGE=1 \
-DDISABLE_PSI_STATEMENT=1
Для получения дополнительной информации см. описания опций
DISABLE_PSI_XXX
CMake в
разделе 2.8.4.
Если Вы устанавливаете MySQL по предыдущей установке, которая была
сконфигурирована без Performance Schema (или с более старой версией
Performance Schema, у которой, возможно, нет всех текущих таблиц), выполните
mysql_upgrade
после запуска сервера, чтобы гарантировать, что база данных
performance_schema существует со всеми текущими таблицами. Тогда
перезапустите сервер. Один признак, что Вы должны сделать это, является
присутствием сообщений, таких как следующее в журнале ошибок:
[ERROR] Native table 'performance_schema'.'events_waits_history'
has the wrong structure
[ERROR] Native table 'performance_schema'.'events_waits_history_long'
has the wrong structure
...
Чтобы проверить, был ли сервер создан с поддержкой Performance Schema,
проверьте ее вывод справки. Если Performance Schema будет доступна, то вывод
упомянет несколько переменных с именами, которые
начинаются с performance_schema:
shell> mysqld --verbose --help
...
--performance_schema
Enable the performance schema.
--performance_schema_events_waits_history_long_size=#
Number of rows in events_waits_history_long.
...
Вы можете также соединиться с сервером и искать строку, которая называет
механизм хранения PERFORMANCE_SCHEMA
в выводе SHOW ENGINES:
mysql> SHOW ENGINES\G
...
Engine: PERFORMANCE_SCHEMA
Support: YES
Comment: Performance Schema
Transactions: NO
XA: NO
Savepoints: NO
...
Если Performance Schema не была сконфигурирована в сервер, никакой строки
для PERFORMANCE_SCHEMA не появится в
выводе SHOW ENGINES.
Вы могли бы видеть performance_schema перечисленную в выводе
SHOW DATABASES, но у этого
не будет никаких таблиц, и Вы не будете в состоянии использовать это.
Строка для PERFORMANCE_SCHEMA в
SHOW ENGINES означает, что
Performance Schema доступна, а не то, что это включено. Чтобы включить, Вы
должны сделать так при запуске сервера, как описано в следующем разделе.
23.2.2.
Конфигурация запуска Performance Schema
Предполагая, что Performance Schema доступна, она включена по умолчанию.
Чтобы включить или отключить это явно, запустите сервер с переменной
performance_schema
, установленной к соответствующему значению. Например, используйте
эти строки в Вашем файле my.cnf:
[mysqld]
performance_schema=ON
Если сервер неспособен выделить какой-либо внутренний буфер во время
инициализации Performance Schema, то Performance Schema отключается и
устанавливает
performance_schema в OFF, а
сервер работает без инструментовки.
Performance Schema также разрешает настроить инструмент и потребительскую
конфигурацию при запуске сервера.
Чтобы управлять инструментом при запуске сервера, используйте
опцию этой формы:
--performance-schema-instrument='instrument_name=value'
Здесь instrument_name инструментальное имя, такое
как wait/synch/mutex/sql/LOCK_open, а
value одно из этих значений:
Каждая опция
--performance-schema-instrument может определить только одно
инструментальное имя, но много копий опции могут быть приведены, чтобы
сконфигурировать много инструментов. Кроме того, образцы разрешены в
инструментальных именах, чтобы сконфигурировать инструменты, которые
соответствуют образцу. Чтобы сконфигурировать все инструменты синхронизации
условия как включенные и считающиеся, используйте эту опцию:
--performance-schema-instrument='wait/synch/cond/%=COUNTED'
Чтобы отключить все инструменты, используйте эту опцию:
--performance-schema-instrument='%=OFF'
Исключение: инструменты memory/performance_schema/%
встроены и не могут быть отключены при запуске.
Более длинные инструментальные строки имен имеют приоритет над более
коротким образцами имен, независимо от порядка. Для информации об определении
образцов, чтобы выбрать инструменты, см.
раздел 23.2.3.9.
Проигнорировано непризнанное инструментальное имя. Возможно, что плагин,
установленный позже, может создать инструмент, в котором
имя признано и сконфигурировано.
Чтобы управлять потребителем при запуске сервера, используйте
опцию этой формы:
--performance-schema-consumer-consumer_name=value
Здесь consumer_name потребительское имя, такое как
events_waits_history, а value
одно из этих значений:
Например, чтобы включить потребителя events_waits_history,
используйте эту опцию:
--performance-schema-consumer-events-waits-history=ON
Разрешенные потребительские имена могут быть найдены, исследуя таблицу
setup_consumers.
Образцы не разрешены. Потребитель называется в таблице
setup_consumers
с применением подчеркивания, но для потребительского набора при запуске тире
и подчеркивания в пределах имени эквивалентны.
Performance Schema включает несколько системных переменных, которые
предоставляют информацию о конфигурации:
mysql> SHOW VARIABLES LIKE 'perf%';
+--------------------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------------------+-------+
| performance_schema | ON |
| performance_schema_accounts_size | 100 |
| performance_schema_digests_size | 200 |
| performance_schema_events_stages_history_long_size | 10000 |
| performance_schema_events_stages_history_size | 10 |
| performance_schema_events_statements_history_long_size | 10000 |
| performance_schema_events_statements_history_size | 10 |
| performance_schema_events_waits_history_long_size | 10000 |
| performance_schema_events_waits_history_size | 10 |
| performance_schema_hosts_size | 100 |
| performance_schema_max_cond_classes | 80 |
| performance_schema_max_cond_instances | 1000 |
...
Переменная
performance_schema ON или OFF, чтобы
указать, включена ли Performance Schema. Другие переменные указывают на
табличные размеры (число строк) или значения распределения памяти.
С включенной Performance Schema число случаев Performance Schema
затрагивает память сервера, возможно в большой степени. Performance Schema
автомасштабирует много параметров, чтобы использовать память только как
требуется, см. раздел
23.14.
Чтобы изменить значение системных переменных Performance Schema,
установите их при запуске сервера. Например, поместите следующие строки в
файл my.cnf, чтобы изменить размеры таблиц истории для события:
[mysqld]
performance_schema
performance_schema_events_waits_history_size=20
performance_schema_events_waits_history_long_size=15000
Performance Schema автоматически измеряет значения нескольких из ее
параметров при запуске сервера, если они не установлены явно. Например, это
измеряет параметры, которые управляют размерами событий. Performance Schema
выделяет память, масштабируя ее использование к фактической загрузке сервера
вместо того, чтобы выделить всю память, которая требуется во время запуска
сервера. Следовательно, много параметров калибровки не должны быть
установлены вообще. Чтобы видеть, какие параметры автоизмерены или
автомасштабируются, используйте
mysqld --verbose --help и исследуйте описания опции.
Для каждого авторазмерного параметра, который не установлен при запуске
сервера (или установле в -1) Performance Schema определяет, как установить
значение, основанное на значении следующих системных значений, которые
рассматривают как подсказки о том, как Вы сконфигурировали
свой сервер MySQL:
max_connections
open_files_limit
table_definition_cache
table_open_cache
Чтобы переопределить автокалибровку или автомасштабирование для данного
параметра, установите это в значение не -1 при запуске. В этом случае
Performance Schema назначает этому указанное значение.
Во временя выполнения SHOW
VARIABLES выводит на экран фактические значения, к которым были
установлены автоизмеренные параметры. Автомасштабируемые параметры выводятся
на экран со значением -1.
Если Performance Schema отключена, ее авторазмерные и автомасштабируемые
параметры остаются установленными в -1 и
SHOW VARIABLES покажет -1.
23.2.3.
Конфигурация Performance Schema во время работы
Таблицы установки Performance Schema
содержат информацию о контролирующей конфигурации:
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'performance_schema' AND
TABLE_NAME LIKE 'setup%';
+-------------------+
| TABLE_NAME |
+-------------------+
| setup_actors |
| setup_consumers |
| setup_instruments |
| setup_objects |
| setup_timers |
+-------------------+
Вы можете исследовать содержание этих таблиц, чтобы получить информацию о
Performance Schema, контролирующей характеристики. Если Вы имеете привилегию
UPDATE, Вы можете
изменить работу Performance Schema, изменяя таблицы установки, чтобы
затронуть, как происходит контроль. Для дополнительных деталей об этих
таблицах см. раздел
23.9.2.
Чтобы видеть, какие таймеры событий выбраны, запросите
setup_timers:
mysql> SELECT * FROM setup_timers;
+-------------+-------------+
| NAME | TIMER_NAME |
+-------------+-------------+
| idle | MICROSECOND |
| wait | CYCLE |
| stage | NANOSECOND |
| statement | NANOSECOND |
| transaction | NANOSECOND |
+-------------+-------------+
NAME указывает на тип инструмента, к которому таймер
применяется, а TIMER_NAME указывает, какой таймер относится к
тем инструментам. Таймер относится к инструментам, где их имя начинается с
компонента, соответствующего NAME.
Чтобы изменить таймер, обновите NAME. Например, чтобы
использовать таймер NANOSECOND для wait:
mysql> UPDATE setup_timers SET TIMER_NAME = 'NANOSECOND'
WHERE NAME = 'wait';
mysql> SELECT * FROM setup_timers;
+-------------+-------------+
| NAME | TIMER_NAME |
+-------------+-------------+
| idle | MICROSECOND |
| wait | NANOSECOND |
| stage | NANOSECOND |
| statement | NANOSECOND |
| transaction | NANOSECOND |
+-------------+-------------+
Таблицы
setup_instruments и
setup_consumers приводят инструменты, для которых события
могут быть собраны и типы потребителей, для которых информация о событии
фактически собрана, соответственно. Другие таблицы установки позволяют
дальнейшей модификации контролирующей конфигурации.
Раздел 23.2.3.2
обсуждает, как Вы можете изменить эти таблицы, чтобы затронуть набор событий.
Если есть изменения конфигурации Performance Schema, которые должны быть
произведены во время выполнения, используя запросы SQL, и Вы хотели бы, чтобы
эти изменения вступили в силу каждый раз, когда сервер запускается, поместите
эти запросы в файл и запускайте сервер с опцией
--init-file=
file_name. Эта стратегия может также быть полезной,
если у Вас есть много контрольных конфигураций, каждая чтобы произвести
различный вид контроля. Поместите запросы для каждой контрольной конфигурации
в их собственный файл и определите соответствующий файл как параметр
--init-file,
когда Вы запускаете сервер.
23.2.3.1.
Синхронизация событий Performance Schema
События собраны посредством инструментовки, добавленной к исходному коду
сервера. Инструментальные события времени обеспечивают сведения о том,
сколько времени события берут. Также возможно сконфигурировать инструменты,
чтобы не собирать информацию синхронизации. Этот раздел обсуждает доступные
таймеры, их характеристики, и как значения
синхронизации представлены в событиях.
Таймеры Performance Schema
Две таблицы Performance Schema предоставляют информацию о таймере:
Каждая строка таймера в
setup_timers должна обратиться к одному из таймеров, перечисленных
в performance_timers
.
Таймеры изменяются по точности и издержкам. Чтобы видеть, какие таймеры
доступны и их характеристики, проверьте таблицу
performance_timers
:
mysql> SELECT * FROM performance_timers;
+-------------+-----------------+------------------+----------------+
| TIMER_NAME | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+-------------+-----------------+------------------+----------------+
| CYCLE | 2389029850 | 1 | 72 |
| NANOSECOND | 1000000000 | 1 | 112 |
| MICROSECOND | 1000000 | 1 | 136 |
| MILLISECOND | 1036 | 1 | 168 |
| TICK | 105 | 1 | 2416 |
+-------------+-----------------+------------------+----------------+
У столбцов есть эти значения:
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() может взять сотни циклов,
что является недопустимыми издержками для того, что может произойти тысячи
или миллионы раз в секунду.
У счетчиков цикла также есть недостатки:
MySQL работает со счетчиками цикла на x386 (Windows, OS X,
Linux, Solaris и другие разновидности Unix), PowerPC и IA-64.
Представление таймера Performance Schema в событиях
У строк в таблицах Performance Schema, которые хранят текущие и
исторические события, есть три столбца, чтобы представить информацию о
синхронизации: TIMER_START и TIMER_END указывают,
когда случай запустился и закончился, а TIMER_WAIT
указывает на продолжительность события.
Таблица
setup_instruments имеет столбец ENABLED, чтобы
указать на инструменты, для которых можно собрать события. У таблицы также
есть столбец TIMED, чтобы указать, какие инструменты рассчитаны.
Если инструмент не включен, он не производит событий. Если включенный
инструмент не рассчитан, события, произведенные инструментом, имеют
NULL для значений таймера TIMER_START,
TIMER_END и TIMER_WAIT. Это в свою очередь
заставляет проигнорировать те значения, вычисляя сумму, минимум, максимум и
средние временные оценки в сводных таблицах.
Внутренне, времена в пределах событий сохранены в модулях, данных таймером
в действительности, когда синхронизация событий начинается. Для отображения,
когда события получены от таблиц Performance Schema времена показываются в
пикосекундах и нормализуются к стандартному модулю, независимо от
которого выбран таймер.
Модификации таблицы
setup_timers
применяются немедленно. События, уже происходящие, могут использовать
оригинальный таймер в течение времени начала и новый таймер в течение времени
окончания. Чтобы избежать непредсказуемых результатов после того, как Вы
производите изменения таймера, надо использовать
TRUNCATE TABLE, чтобы
сбрасывать статистику Performance Schema.
Базовая линия таймера (нулевое время) происходит при
инициализации Performance Schema во время запуска сервера. Значения
TIMER_START и TIMER_END
в событиях представляют пикосекунды, начиная с базовой линии. Значения
TIMER_WAIT указывают продолжительности в пикосекундах.
Значения пикосекунды в событиях приблизительны. Их точность подвергается
обычным формам ошибки, связанной с преобразованием от одного модуля до
другого. Если таймер CYCLE используется, и уровень процессора
изменяется, мог бы быть дрейф. По этим причинам неразумно смотреть на
значение TIMER_START как на точную меру времени, начиная с
запуска сервера. С другой стороны, разумно использовать
TIMER_START или TIMER_WAIT в ORDER BY,
чтобы упорядочить события по времени запуска или продолжительности.
У выбора пикосекунд в событиях, а не таких значений, как микросекунды
есть исполнительное основание. Одна цель выполнения состояла в том, чтобы
показать результаты в однородной единице измерения времени, независимо от
таймера. В идеальном мире эта единица измерения времени была бы похожа на
модуль стенных часов и была бы разумно точна, другими словами, микросекунды.
Но преобразовать циклы или наносекунды к микросекундам, было бы необходимо
выполнить деление для каждой инструментовки. Деление дорого на многих
платформах. Умножение не дорого, так что оно и используется.
Поэтому, единица измерения времени целое число, полученное из максимально
возможного TIMER_FREQUENCY, используя множитель, достаточно
большой, чтобы гарантировать, что нет никакой крупной потери точности.
Результат состоит в том, что единица измерения времени пикосекунда
. Эта точность является поддельной, но решение минимизирует издержки.
В то время как ожидание, этап, запрос или операционный случай выполняются,
соответствующие таблицы текущих событий выводят на экран информацию о
синхронизации текущих событий:
events_waits_current
events_stages_current
events_statements_current
events_transactions_current
Чтобы позволить определить, сколько времени завершенный случай работал,
столбцы таймера установлены следующим образом:
TIMER_START заполнен.
TIMER_END заполнен текущим значением таймера.TIMER_WAIT заполнен временем, прошедшим до сих пор
(TIMER_END-TIMER_START).
События, которые еще не завершились, имеют значение
END_EVENT_ID NULL.
Чтобы оценить прошедшее время для случая, используйте столбец
TIMER_WAIT. Поэтому, чтобы идентифицировать события, которые еще
не завершились и заняли больше времени, чем N
пикосекунд к настоящему времени, приложения могут использовать
это выражение в запросах:
WHERE END_EVENT_ID IS NULL AND TIMER_WAIT > N
Идентификация событий как только описано предполагает, что соответствующие
инструменты имеют ENABLED и TIMED установленные в
YES, а соответствующие потребители включены.
23.2.3.2.
Фильтрация событий Performance Schema
События обработаны способом производителя/потребителя:
Инструментованный код производит события, которые будут собраны.
Таблица setup_instruments
приводит инструменты, для которых могут быть собраны события,
включены ли они и (для включенных инструментов), собирать
ли информацию синхронизации:
mysql> SELECT * FROM setup_instruments;
+---------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+---------------------------------------------------+---------+-------+
...
| wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES |
| wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES |
| wait/synch/mutex/sql/LOCK_lock_db | YES | YES |
| wait/synch/mutex/sql/LOCK_manager | YES | YES |
...
Таблица
setup_instruments обеспечивает наиболее каноническую форму
управления производством событий. Чтобы далее усовершенствовать производство
событий, основанное на типе объекта или проверяемого потока, другие таблицы
могут использоваться как описано в
разделе 23.2.3.3.
- Таблицы Performance Schema это места назначения для событий и
потребители. Таблица
setup_consumers приводит типы потребителей, в которые можно
послать информацию о событии и включены ли они:
mysql> SELECT * FROM setup_consumers;
+----------------------------------+---------+
| NAME | ENABLED |
+----------------------------------+---------+
| events_stages_current | NO |
| events_stages_history | NO |
| events_stages_history_long | NO |
| events_statements_current | YES |
| events_statements_history | YES |
| events_statements_history_long | NO |
| events_transactions_current | NO |
| events_transactions_history | NO |
| events_transactions_history_long | NO |
| events_waits_current | NO |
| events_waits_history | NO |
| events_waits_history_long | NO |
| global_instrumentation | YES |
| thread_instrumentation | YES |
| statements_digest | YES |
+----------------------------------+---------+
Фильтрация может быть сделана на различных
этапах исполнительного контроля:
Предварительная фильтрация.
Это сделано, изменяя конфигурацию Performance Schema так, чтобы только
определенные типы событий были собраны от производителей, и собранные события
обновляют только определенных потребителей. Чтобы сделать это, включите или
отключите инструменты или потребителей. Предварительная фильтрация сделана
Performance Schema и имеет глобальный эффект, который относится
ко всем пользователям.
Причины использовать предварительную фильтрацию:
Уменьшить издержки. Издержки Performance Schema
должны быть минимальны даже со всеми включенными инструментами, но возможно
Вы хотите уменьшить их далее. Или Вы не заботитесь о событиях синхронизации и
хотите отключить код синхронизации, чтобы устранить издержки синхронизации.
- Избежать заполнения текущих событий или таблицы истории с событиями, к
которым у Вас нет никакого интереса. Предварительная фильтрация оставляет
больше места в этих таблицах для случаев строк включенных инструментальных
типов. Если Вы включаете только инструменты файла с предварительной
фильтрацией, никакие строки не собраны для не файловых инструментов.
С постфильтрацией не файловые события собраны, оставляя меньше строк
для событий файла.
- Избежать поддерживать некоторые виды таблиц событий. Если Вы отключаете
потребителя, сервер не тратит времея для этого потребителя. Например, если Вы
не заботитесь об историях событий, Вы можете отключить табличных потребителей
истории, чтобы улучшить работу.
Постфильтрация. Это вовлекает
использование WHERE в запросах, которые выбирают информацию из
таблиц Performance Schema, чтобы определить, какое из доступных событий Вы
хотите видеть. Постфильтрация выполнена в расчёте на пользователя, потому что
отдельные пользователи выбирают, какие из доступных
событий представляют интерес.
Причины использовать постфильтрацию:
Следующие разделы обеспечивают больше деталей о предварительной фильтрации
и обеспечивают направления для того, чтобы назвать инструменты или
потребителей в фильтрации операций. Для информации о написании
запросов, чтобы получить информацию (постфильтрация) см.
раздел 23.3.
23.2.3.3.
Предварительная фильтрация событий
Предварительная фильтрация сделана Performance Schema
и имеет глобальный эффект, который относится ко всем пользователям.
Предварительная фильтрация может быть применена к производителю или к
потребителю обработки событий:
Чтобы сконфигурировать предварительную фильтрацию на этапе
производителя, несколько таблиц могут использоваться:
setup_instruments указывает, какие инструменты доступны.
Инструмент, отключенный в этой таблице, не производит событий независимо от
содержания других связанных с производством таблиц. Инструменту, включенному
в этой таблице, разрешают произвести события, согласно
содержанию других таблиц.
setup_objects
контролирует особые таблицы Performance Schema и хранит объекты программы.
threads
указывает, включен ли контроль для каждого потока сервера.setup_actors
определяет начальное контрольное состояние
для новых потоков переднего плана.
Чтобы сконфигурировать предварительную фильтрацию на потребительском
этапе, измените таблицу
setup_consumers. Это определяет места назначения, в которые
посылают события. Если данный случай не пошлют ни к какому месту назначения
(то есть, он не будет потребляться), Performance Schema не производит его.
Модификации любой из этих таблиц действуют немедленно, за исключением
того, что модификации
setup_actors влияют только на потоки переднего плана, созданные
после модификации, а не на существующие потоки.
Когда Вы изменяете контролирующую конфигурацию, Performance Schema
не сбрасывает таблицы истории. События, уже собранные, остаются в текущих
событиях и таблицах истории пока не перемещены более новыми событиями. Если
Вы отключаете инструменты, Вы, возможно, должны были бы ждать некоторое время
прежде, чем события для них перемещены более новыми мероприятиями.
Альтернативно, можно использовать
TRUNCATE TABLE, чтобы
освободить таблицы истории.
После произведения изменений инструментовки Вы могли бы хотеть усечь
сводные таблицы. Вообще, эффект состоит в том, чтобы сбросить сводные столбцы
к 0 или NULL, а не удалить строки. Это могло бы быть полезно,
например, после того, как Вы произвели изменение конфигурации во время
выполнения. Исключения к этому поведению усечения отмечены в отдельных
разделах сводной таблицы.
Следующие разделы описывают, как использовать определенные таблицы, чтобы
управлять предварительной фильтрацией Performance Schema.
23.2.3.4.
Предварительная фильтрация по инструменту
Таблица
setup_instruments приводит доступные инструменты:
mysql> SELECT * FROM setup_instruments;
+---------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+---------------------------------------------------+---------+-------+
...
| wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES |
| wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES |
| wait/synch/mutex/sql/LOCK_lock_db | YES | YES |
| wait/synch/mutex/sql/LOCK_manager | YES | YES |
...
| wait/synch/rwlock/sql/LOCK_grant | YES | YES |
| wait/synch/rwlock/sql/LOGGER::LOCK_logger | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_connect | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_slave | YES | YES |
...
| wait/io/file/sql/binlog | YES | YES |
| wait/io/file/sql/binlog_index | YES | YES |
| wait/io/file/sql/casetest | YES | YES |
| wait/io/file/sql/dbopt | YES | YES |
...
Чтобы управлять, включен ли инструмент, устанавливайте столбец
ENABLED в YES или NO.
Чтобы сконфигурировать, собирать ли информацию синхронизации для включенного
инструмента, установите TIMED в YES или
NO. Установка TIMED затрагивает табличное
содержание Performance Schema как описано в
разделе 23.2.3.1.
Модификации большинства строк
setup_instruments
действуют немедленно. Для некоторых инструментов модификации эффективны
только при запуске сервера, изменение их во время выполнения не имеет
никакого эффекта. Это затрагивает прежде всего mutexes, условия и rwlocks в
сервере, хотя могут быть другие инструменты, для которых это истина.
Таблица
setup_instruments обеспечивает наиболее каноническую форму
управления производством событий. Чтобы далее усовершенствовать производство
событий, основанное на типе объекта или проверяемого потока, другие таблицы
могут использоваться как описано в
разделе 23.2.3.3.
Следующие примеры демонстрируют возможные операции на
setup_instruments
. Эти изменения, как другие операции перед фильтрацией, затрагивают всех
пользователей. Некоторые из этих запросов используют оператор
LIKE и инструмент
соответствия образца. Для дополнительной информации об определении образцов,
чтобы выбрать инструменты см.
раздел 23.2.3.9.
Отключите все инструменты:
mysql> UPDATE setup_instruments SET ENABLED = 'NO';
Теперь никакие события не будут собраны. - Отключите все инструменты файла, добавляя их к текущему
набору отключенных инструментов:
mysql> UPDATE setup_instruments SET ENABLED = 'NO'
WHERE NAME LIKE 'wait/io/file/%';
- Отключите только инструменты файла, включите все другие инструменты:
mysql> UPDATE setup_instruments
SET ENABLED = IF(NAME LIKE 'wait/io/file/%', 'NO', 'YES');
- Включите все, кроме инструментов в библиотеке
mysys:
mysql> UPDATE setup_instruments SET ENABLED = CASE
WHEN NAME LIKE '%/mysys/%' THEN 'YES' ELSE 'NO' END;
- Отключите определенный инструмент:
mysql> UPDATE setup_instruments SET ENABLED = 'NO'
WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';
- Переключите статус инструмента flip:
mysql> UPDATE setup_instruments
SET ENABLED = IF(ENABLED = 'YES','NO','YES')
WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';
- Отключите синхронизацию для всех событий:
mysql> UPDATE setup_instruments SET TIMED = 'NO';
23.2.3.5.
Предварительная фильтрация по объекту
Таблица setup_objects
управляет, контролирует ли Performance Schema
особую таблицу и хранение объектов программы. Начальное содержимое
setup_objects
похоже на это:
mysql> SELECT * FROM setup_objects;
+-------------+--------------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED |
+-------------+--------------------+-------------+---------+-------+
| EVENT | mysql | % | NO | NO |
| EVENT | performance_schema | % | NO | NO |
| EVENT | information_schema | % | NO | NO |
| EVENT | % | % | YES | YES |
| FUNCTION | mysql | % | NO | NO |
| FUNCTION | performance_schema | % | NO | NO |
| FUNCTION | information_schema | % | NO | NO |
| FUNCTION | % | % | YES | YES |
| PROCEDURE | mysql | % | NO | NO |
| PROCEDURE | performance_schema | % | NO | NO |
| PROCEDURE | information_schema | % | NO | NO |
| PROCEDURE | % | % | YES | YES |
| TABLE | mysql | % | NO | NO |
| TABLE | performance_schema | % | NO | NO |
| TABLE | information_schema | % | NO | NO |
| TABLE | % | % | YES | YES |
| TRIGGER | mysql | % | NO | NO |
| TRIGGER | performance_schema | % | NO | NO |
| TRIGGER | information_schema | % | NO | NO |
| TRIGGER | % | % | YES | YES |
+-------------+--------------------+-------------+---------+-------+
Модификации setup_objects
вступают в силу немедленно.
Столбец OBJECT_TYPE указывает на тип объекта, к которому
применяется строка. TABLE фильтрует табличные события
ввода/вывода (инструмент wait/io/table/sql/handler) и
события блокировки (инструментwait/lock/table/sql/handler).
Столбцы OBJECT_SCHEMA и OBJECT_NAME
должны содержать буквальную схему или название объекта или '%',
чтобы соответствовать любому имени.
Столбец ENABLED указывает, проверены ли соответствующие
объекты, а TIMED указывает, собирать ли информацию
синхронизации. Установка TIMED затрагивает табличное содержание
Performance Schema как описано в
разделе 23.2.3.1.
Эффект конфигурации объекта по умолчанию состоит в том, чтобы
инструментовать все объекты кроме тех, которые в базах данных
mysql, INFORMATION_SCHEMA и
performance_schema. Таблицы в INFORMATION_SCHEMA
не инструментованы независимо от содержания
setup_objects:
строка для information_schema.%
просто делает это значение по умолчанию явным.
Когда Performance Schema проверяет на соответствие в
setup_objects,
это пытается найти более определенные соответствия сначала. Для строк,
которые соответствуют данному OBJECT_TYPE, Performance Schema
проверяет строки в этом порядке:
Например, с таблицей 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:
Подобная логика просит объединения столбцов TIMED из
setup_instruments
и setup_objects
, чтобы определить, собирать ли информацию синхронизации событий.
Если у постоянной и временной таблиц есть то же самое имя, соответствующее
строке setup_objects
происходит тот же самый путь к обоим. Невозможно позволить
контролировать для одной таблицы, но не для другой.
Однако, каждая таблица инструментована отдельно.
23.2.3.6.
Предварительная фильтрация по потоку
Таблица threads
содержит строку для каждого потока сервера. Каждая строка содержит информацию
о потоке и указывает, включен ли контроль для этого. Для Performance Schema,
чтобы контролировать поток, эти вещи должны быть истиной:
Таблица threads
также показывает для каждого потока сервера, выполнить ли журналирование
исторического события. Это включает ожидание, подготовку, запрос и
операционное журналирование событий для этих таблиц:
events_waits_history
events_waits_history_long
events_stages_history
events_stages_history_long
events_statements_history
events_statements_history_long
events_transactions_history
events_transactions_history_long
Для журналирования исторического события эти вещи должны быть истиной:
Соответствующие связанные с историей потребители в
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 не использован):
Порядок, в котором соответствие происходит таков,
потому что различные соответствующие строки
setup_actors
могут иметь отличающиеся USER и HOST.
Это позволяет инструментовать и журналировать события, которые будут
применены выборочно на основе узла, пользователя или учетной записи
(комбинация пользователя и узла), исходя из значения столбцов:
ENABLED и HISTORY:
Столбцы ENABLED и HISTORY в строках
setup_actors
могут быть установлены в YES или NO
независимо друг от друга. Это означает, что Вы можете включить инструментовку
отдельно от того, собираете ли Вы исторические события.
По умолчанию контроль и набор исторического события включен для всех
новых потоков переднего плана потому, что
setup_actors
первоначально содержит строку с '%' для
HOST и USER. Чтобы выполнить более ограниченное
соответствие, например, позволить контролировать только для некоторых потоков
переднего плана, Вы должны изменить эту строку, потому что это соответствует
любому соединению, и добавить строки для более определенной комбинации
HOST/USER.
Предположите, что Вы изменяете
setup_actors следующим образом:
UPDATE setup_actors SET ENABLED = 'NO', HISTORY = 'NO'
WHERE HOST = '%' AND USER = '%';
INSERT INTO setup_actors (HOST,USER,ROLE,ENABLED,HISTORY)
VALUES('localhost','joe','%','YES','YES');
INSERT INTO setup_actors (HOST,USER,ROLE,ENABLED,HISTORY)
VALUES('hosta.example.com','joe','%','YES','NO');
INSERT INTO setup_actors (HOST,USER,ROLE,ENABLED,HISTORY)
VALUES('%','sam','%','NO','YES');
UPDATE изменяет соответствие по
умолчанию, чтобы отключить набор исторического события и инструментовку.
INSERT
добавляют строки для более определенных соответствий.
Теперь Performance Schema определяет, как установить значения
INSTRUMENTED и HISTORY
для потока нового соединения следующим образом:
Модификации setup_actors
влияют только на потоки переднего плана, созданные после
модификации, а не на существующие потоки. Чтобы затронуть существующие
потоки, измените INSTRUMENTED и HISTORY строках
таблицы threads.
23.2.3.7.
Предварительная фильтрация по потребителю
setup_consumers
приводит доступные потребительские типы и то, которые включены:
mysql> SELECT * FROM setup_consumers;
+----------------------------------+---------+
| NAME | ENABLED |
+----------------------------------+---------+
| events_stages_current | NO |
| events_stages_history | NO |
| events_stages_history_long | NO |
| events_statements_current | YES |
| events_statements_history | YES |
| events_statements_history_long | NO |
| events_transactions_current | NO |
| events_transactions_history | NO |
| events_transactions_history_long | NO |
| events_waits_current | NO |
| events_waits_history | NO |
| events_waits_history_long | NO |
| global_instrumentation | YES |
| thread_instrumentation | YES |
| statements_digest | YES |
+----------------------------------+---------+
Измените setup_consumers
, чтобы затронуть предварительную фильтрацию в потребителе
и определить места назначения, в которые посылают события. Чтобы включить или
отключить потребителя, установите ENABLED в
YES или NO.
Модификации
setup_consumers срабатывают немедленно.
Если Вы отключаете потребителя, сервер не тратит времени на поддержание
места назначения для этого потребителя. Например, если Вы не заботитесь об
информации об историческом событии, отключите потребителей истории:
mysql> UPDATE setup_consumers SET ENABLED = 'NO' WHERE NAME
LIKE '%history%';
Потребительские настройки в
setup_consumers имеют иерархию.
Следующие принципы применяются:
Места назначения, связанные с потребителем, не получают событий,
если Performance Schema не проверяет потребителя. - Потребитель проверен, только если все потребители, от которых он
зависит (если такие есть), включены.
- Если потребитель не проверен, или проверен, но отключен, другие
потребители, которые зависят от него, не проверены.
- У зависимых потребителей могут быть свои
собственные зависимые потребители.
- Если случай не послан никакому месту назначения, Performance Schema
не производит его.
Следующие списки описывают доступные потребительские значения. Для
обсуждения нескольких потребительских конфигураций и их эффекта
на инструментовку см.
раздел
23.2.3.8.
Глобальные и потребители потока
global_instrumentation потребитель высшего уровня.
Если global_instrumentation NO,
это отключает глобальную инструментовку. Все другие настройки более низкого
уровня и не проверены, не имеет значения, во что они установлены. Нет
глобальной или поточной информацим о потоке, и никакие одиночные события
не собраны в таблицах истории событий или текущих событиях. Если
global_instrumentation YES, Performance Schema
поддерживает информацию для глобальных состояний, а также проверяет
потребителей thread_instrumentation.
thread_instrumentation проверен только, если
global_instrumentation YES. Иначе, если
thread_instrumentation NO,
это отключает определенную для потока инструментовку, и все настройки низшего
уровня проигнорированы. Никакая информация не поддержана для потока, и
никакие одиночные события не собраны в таблицах истории событий или текущих
событиях. Если thread_instrumentation YES,
Performance Schema поддерживает определенную для потока информацию, а также
проверяет events_xxx_current.
Потребители событий ожидания
Эти потребители требуют установки обоих
global_instrumentation и thread_instrumentation в
YES или они не проверены. Если проверены, они
действуют следующим образом:
events_waits_current, если NO,
отключает сбор индивидуальных событий ожидания в таблице
events_waits_current
. Если YES, это включает сбор событий и
Performance Schema проверяет events_waits_history и
events_waits_history_long.
events_waits_history не проверен, если
event_waits_current NO. Иначе
events_waits_history NO или YES
отключает или включает сбор событий в таблице
events_waits_history
.events_waits_history_long не проверен, если
event_waits_current NO. Иначе
events_waits_history_long NO или YES
отключает или включает сбор событий в таблице
events_waits_history_long.
Потребители событий этапа
Эти потребители требуют global_instrumentation и
thread_instrumentation в YES
или они не проверены. Если проверены, действуют следующим образом:
events_stages_current, если NO,
отключает сбор отдельных событий этапа в таблице
events_stages_current
. Если YES, это включает сбор этапов событий, и
Performance Schema проверяет events_stages_history и
events_stages_history_long.
events_stages_history не проверен, если
event_stages_current NO. Иначе
events_stages_history NO или YES
отключает или включает сбор событий этапа в
events_stages_history
.events_stages_history_long не проверен, если
event_stages_current NO. Иначе
events_stages_history_long NO или YES
отключает или включает сбор событий этапа в
events_stages_history_long.
Потребители событий запроса
Эти потребители требуют global_instrumentation и
thread_instrumentation в YES
или они не проверены. Если проверены, действуют следующим образом:
events_statements_current, если NO,
отключает сбор отдельных событий запроса в таблице
events_statements_current. Если YES,
это включает сбор запросов событий, и Performance Schema проверяет
events_statements_history и
events_statements_history_long.
events_statements_history не проверен, если
events_statements_current NO. Иначе
events_statements_history NO или YES
отключает или включает сбор событий запроса в таблице
events_statements_history.events_statements_history_long не проверен, если
events_statements_current NO. Иначе
events_statements_history_long NO или
YES отключает или включает сбор событий запроса в таблице
events_statements_history_long.
Операционные потребители событий
Эти потребители требуют global_instrumentation и
thread_instrumentation YES
или они не проверены. Если проверены, они действуют следующим образом:
events_transactions_current, если
NO, отключает сбор отдельных операционных событий в таблице
events_transactions_current. Если YES,
это включает сбор операционных событий, и Performance Schema проверяет
events_transactions_history и
events_transactions_history_long.
events_transactions_history не проверен, если
events_transactions_current NO. Иначе
events_transactions_history NO или YES
отключает или включает сбор операционных событий в таблице
events_transactions_history.events_transactions_history_long не проверен, если
events_transactions_current NO. Иначе
events_transactions_history_long
NO или YES
отключает или включает сбор операционных событий в таблице
events_transactions_history_long.
Потребитель обзора запросов
Этот потребитель требует global_instrumentation
YES или это не проверено. Нет никакой зависимости от
потребителей событий запросов, таким образом, Вы можете получить статистику
обзоров, не имея необходимости собирать статистические данные в
events_statements_current, что выгодно с точки зрения издержек.
Наоборот, Вы можете вложить детализированные запросы
events_statements_current без обзоров (столбцы DIGEST
и DIGEST_TEXT должны быть NULL).
23.2.3.8.
Потребительские конфигурации в качестве примера
Потребительские настройки в таблице
setup_consumers
имеют иерархию. Следующее обсуждение описывает, как потребители работают,
показывая определенные конфигурации и их эффекты. Общие принципы, описанные
здесь, относятся к другим потребительским значениям, которые
могут быть доступны.
Описания конфигурации происходят в порядке увеличивающейся
функциональности. Если Вы не нуждаетесь в информации, предоставленной,
включая настройками низшего уровня, отключите их, и Performance Schema
выполнит меньше кода от Вашего имени.
Таблица setup_consumers
содержит следующую иерархию значений:
global_instrumentation
thread_instrumentation
events_waits_current
events_waits_history
events_waits_history_long
events_stages_current
events_stages_history
events_stages_history_long
events_statements_current
events_statements_history
events_statements_history_long
events_transactions_current
events_transactions_history
events_transactions_history_long
statements_digest
В потребительской иерархии потребители для ожиданий, этапов, запросов и
транзакции все на том же самом уровне. Это отличается от иерархии вложения
событий, где события вложены по уровням.
Если данный потребитель устанавливает NO, Performance Schema
отключает инструментовку, связанную с потребителем, и игнорирует все
настройки низшего уровня. Если данная установка YES, Performance
Schema включает инструментовку, связанную с этим, и проверяет настройки на
следующем самом низком уровне. Для описания правил для каждого потребителя
см. раздел
23.2.3.7.
Например, если global_instrumentation включен,
thread_instrumentation проверен. Если
thread_instrumentation включен, потребители
events_xxx_current проверены. Если из них
events_waits_current включен,
events_waits_history и
events_waits_history_long проверены.
Каждое из следующих описаний конфигурации указывает, какие элементы
установки проверки Performance Schema выводят таблицы, которые она
поддерживает (то есть, для которых таблиц она собирает информацию).
Никакой инструментовки
Состояние конфигурации сервера:
mysql> SELECT * FROM setup_consumers;
+---------------------------+---------+
| NAME | ENABLED |
+---------------------------+---------+
| global_instrumentation | NO |
...
+---------------------------+---------+
В этой конфигурации ничто не инструментовано.
Элементы установки проверяют:
Выходные таблицы поддержаны:
Только глобальная инструментовка
Состояние конфигурации сервера:
mysql> SELECT * FROM setup_consumers;
+---------------------------+---------+
| NAME | ENABLED |
+---------------------------+---------+
| global_instrumentation | YES |
| thread_instrumentation | NO |
...
+---------------------------+---------+
В этой конфигурации инструментовка поддержана только для глобальных
состояний. Инструментовка потоков отключена.
Дополнительные проверенные элементы установки,
относительно предыдущей конфигурации:
Дополнительные выходные таблицы, относительно предыдущей конфигурации:
Инструментовка глобальная и потока
Состояние конфигурации сервера:
mysql> SELECT * FROM setup_consumers;
+----------------------------------+---------+
| NAME | ENABLED |
+----------------------------------+---------+
| global_instrumentation | YES |
| thread_instrumentation | YES |
| events_waits_current | NO |
...
| events_stages_current | NO |
...
| events_statements_current | NO |
...
| events_transactions_current | NO |
...
+----------------------------------+---------+
В этой конфигурации инструментовка поддержана глобально и для потоков.
Никакие одиночные события не собраны в таблицах истории событий
или текущих событиях.
Дополнительные проверенные элементы установки,
относительно предыдущей конфигурации:
Таблица
setup_consumers, потребители events_xxx
_current, где xxx
waits, stages,
statements, transactions. - Таблица
setup_actors
.
- Столбец
threads.instrumented.
Дополнительные выходные поддержанные таблицы,
относительно предыдущей конфигурации:
events_xxx_summary_by_yyy
_by_event_name, где xxx
waits, stages, statements,
transactions, а yyy
thread, user,
host, account.
Инструментовка текущих событий, глобальная и потока
Состояние конфигурации сервера:
mysql> SELECT * FROM setup_consumers;
+----------------------------------+---------+
| NAME | ENABLED |
+----------------------------------+---------+
| global_instrumentation | YES |
| thread_instrumentation | YES |
| events_waits_current | YES |
| events_waits_history | NO |
| events_waits_history_long | NO |
| events_stages_current | YES |
| events_stages_history | NO |
| events_stages_history_long | NO |
| events_statements_current | YES |
| events_statements_history | YES |
| events_statements_history_long | NO |
| events_transactions_current | YES |
| events_transactions_history | YES |
| events_transactions_history_long | NO |
...
+----------------------------------+---------+
В этой конфигурации инструментовка поддержана глобально и для потока.
Одиночные события собраны в таблице текущих событий, но не в
таблицах истории событий.
Дополнительные проверенные элементы установки,
относительно предыдущей конфигурации:
Потребители events_xxx_history,
где xxx waits, stages,
statements, transactions. - Потребители
events_xxx_history_long,
где xxx waits, stages,
statements, transactions.
Дополнительные выходные поддержанные таблицы,
относительно предыдущей конфигурации:
events_xxx_current,
где xxx is waits, stages,
statements, transactions.
Инструментовка текущих событий, стории событий, глобальная и потока
Предыдущая конфигурация не собирает историю событий потому, что
потребители events_xxx_history
и events_xxx_history_long отключены.
Эти потребители можно включить отдельно или вместе, чтобы собрать историю
событий для потока, глобально или обоими способами.
Эта конфигурация собирает историю событий для потока, но не глобально:
mysql> SELECT * FROM setup_consumers;
+----------------------------------+---------+
| NAME | ENABLED |
+----------------------------------+---------+
| global_instrumentation | YES |
| thread_instrumentation | YES |
| events_waits_current | YES |
| events_waits_history | YES |
| events_waits_history_long | NO |
| events_stages_current | YES |
| events_stages_history | YES |
| events_stages_history_long | NO |
| events_statements_current | YES |
| events_statements_history | YES |
| events_statements_history_long | NO |
| events_transactions_current | YES |
| events_transactions_history | YES |
| events_transactions_history_long | NO |
...
+----------------------------------+---------+
Таблицы истории событий для этой конфигурации:
events_xxx_history, где
xxx waits, stages,
statements, transactions.
Эта конфигурация собирает историю событий глобально, но не для потока:
mysql> SELECT * FROM setup_consumers;
+----------------------------------+---------+
| NAME | ENABLED |
+----------------------------------+---------+
| global_instrumentation | YES |
| thread_instrumentation | YES |
| events_waits_current | YES |
| events_waits_history | NO |
| events_waits_history_long | YES |
| events_stages_current | YES |
| events_stages_history | NO |
| events_stages_history_long | YES |
| events_statements_current | YES |
| events_statements_history | YES |
| events_statements_history_long | YES |
| events_transactions_current | YES |
| events_transactions_history | YES |
| events_transactions_history_long | YES |
...
+----------------------------------+---------+
Таблицы истории событий для этой конфигурации:
events_xxx_history_long, где
xxx waits, stages,
statements, transactions.
Эта конфигурация собирает историю событий для потока и глобально:
mysql> SELECT * FROM setup_consumers;
+----------------------------------+---------+
| NAME | ENABLED |
+----------------------------------+---------+
| global_instrumentation | YES |
| thread_instrumentation | YES |
| events_waits_current | YES |
| events_waits_history | YES |
| events_waits_history_long | YES |
| events_stages_current | YES |
| events_stages_history | YES |
| events_stages_history_long | YES |
| events_statements_current | YES |
| events_statements_history | YES |
| events_statements_history_long | YES |
| events_transactions_current | YES |
| events_transactions_history | YES |
| events_transactions_history_long | YES |
...
+----------------------------------+---------+
Таблицы истории событий для этой конфигурации:
events_xxx_history, где
xxx waits, stages,
statements, transactions.
events_xxx_history_long, где
xxx waits, stages,
statements, transactions.
23.2.3.9.
Обозначение инструментов или потребителей для операций фильтрации
Имена, данные для того, чтобы фильтровать операции, могут быть столь
определенными или общими как требуется. Чтобы указать на единственный
инструмент или потребителя, определите его имя полностью:
mysql> UPDATE setup_instruments SET ENABLED = 'NO'
WHERE NAME = 'wait/synch/mutex/myisammrg/MYRG_INFO::mutex';
mysql> UPDATE setup_consumers
SET ENABLED = 'NO' WHERE NAME = 'events_waits_current';
Чтобы определить группу инструментов или потребителей, используйте
образец, который соответствует членам группы:
mysql> UPDATE setup_instruments SET ENABLED = 'NO'
WHERE NAME LIKE 'wait/synch/mutex/%';
mysql> UPDATE setup_consumers SET ENABLED = 'NO'
WHERE NAME LIKE '%history%';
Если Вы используете образец, это должно быть выбрано так, чтобы
соответствовало всем элементам, представляющим интерес и никаким другим.
Например, чтобы выбрать все инструменты ввода/вывода файла, лучше
использовать образец, который включает всю инструментальную приставку имени:
... WHERE NAME LIKE 'wait/io/file/%';
Образец '%/file/%' будет соответствовать другим инструментам,
у которых есть компонент '/file/'
где угодно в имени. Еще менее подходящий образец '%file%', так
как это будет соответствовать инструментам с 'file'
где угодно в имени, например,
wait/synch/mutex/sql/LOCK_des_key_file.
Чтобы проверить, какой инструмент или потребитель вызывают соответствие
образцу, выполните простой тест:
mysql> SELECT NAME FROM setup_instruments
WHERE NAME LIKE 'pattern';
mysql> SELECT NAME FROM setup_consumers
WHERE NAME LIKE 'pattern';
23.2.3.10.
Определение, что инструментовано
Всегда возможно определить то, что инструментует Performance Schema,
проверяя setup_instruments
. Например, чтобы видеть, какие связанные с файлом события
инструментованы для механизма хранения InnoDB,
используйте этот запрос:
mysql> SELECT * FROM setup_instruments
WHERE NAME LIKE 'wait/io/file/innodb/%';
+--------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+--------------------------------------+---------+-------+
| wait/io/file/innodb/innodb_data_file | YES | YES |
| wait/io/file/innodb/innodb_log_file | YES | YES |
| wait/io/file/innodb/innodb_temp_file | YES | YES |
+--------------------------------------+---------+-------+
Исчерпывающее описание того, что инструментовано, не дано в этой
документации, по нескольким причинам:
То, что инструментовано, является кодом сервера. Изменения этого
кода часто происходят, что также затрагивает набор инструментов. - Непрактично перечислять все инструменты, потому что их сотни.
- Как описано ранее, возможно узнать, запрашивая таблицу
setup_instruments
. Эта информация всегда современна для Вашей версии MySQL, а также
включает инструментовку для плагинов, которые Вы, возможно, установили,
не являющихся частью основного сервера.
Они могут использоваться автоматизированными инструментами.
23.3. Запросы Performance Schema
Предварительная фильтрация ограничивает, какая информация о событии
собрана и независима от любого особого пользователя. В отличие от этого,
постфильтрация выполнена отдельными пользователями с помощью запросов с
соответствующим WHERE, который ограничивает, какая информация о
событии должна быть выбрана из событий, доступных
после предварительной фильтрации.
В разделе 23.2.3.3
, пример показал, как предварительно фильтровать для инструментов файла.
Если таблицы событий содержат информацию о файле и не о файле, постфильтрация
другой способ видеть информацию только для событий файла. Добавьте
WHERE к запросам, чтобы ограничить выбор событий соответственно:
mysql> SELECT THREAD_ID, NUMBER_OF_BYTES FROM events_waits_history
WHERE EVENT_NAME LIKE 'wait/io/file/%' AND
NUMBER_OF_BYTES IS NOT NULL;
+-----------+-----------------+
| THREAD_ID | NUMBER_OF_BYTES |
+-----------+-----------------+
| 11 | 66 |
| 11 | 47 |
| 11 | 139 |
| 5 | 24 |
| 5 | 834 |
+-----------+-----------------+
Большинство таблиц Performance Schema имеют индекс, который предоставляет
оптимизатору доступ к планам выполнения кроме полного сканирования таблицы.
Они также улучшают работу для связанных объектов, таких как представления
sys schema, которые используют те таблицы.
Для получения дополнительной информации см.
раздел 9.2.5.
23.4.
Соглашения о присвоении имен инструментам Performance Schema
Инструментальное имя состоит из последовательности компонентов, отделенных
'/' Имена в качестве примера:
wait/io/file/myisam/log
wait/io/file/mysys/charset
wait/lock/table/sql/handler
wait/synch/cond/mysys/COND_alarm
wait/synch/cond/sql/BINLOG::update_cond
wait/synch/mutex/mysys/BITMAP_mutex
wait/synch/mutex/sql/LOCK_delete
wait/synch/rwlock/sql/Query_cache_query::lock
stage/sql/closing tables
stage/sql/Sorting result
statement/com/Execute
statement/com/Query
statement/sql/create_table
statement/sql/lock_tables
errors
У инструментального пространства имен есть подобная дереву структура.
Компоненты инструментального имени слева направо обеспечивают прогрессию от
более общего до более определенного. Число компонентов, которые имеет имя,
зависит от типа инструмента.
Интерпретация данного компонента зависит от компонентов слева от этого.
Например, myisam появляется в обоих из следующих имен, но
myisam в первом имени связан с вводом/выводом файла, тогда как
во втором это связано с инструментом синхронизации:
wait/io/file/myisam/log
wait/synch/cond/myisam/MI_SORT_INFO::cond
Инструментальные имена состоят из приставки со структурой, определенной
выполнением Performance Schema и суффиксом, определенным разработчиком,
осуществляющим инструментальный код. Высокоуровневый компонент
инструментальной приставки указывает на тип инструмента. Этот компонент также
определяет, который таймер событий в setup_timers относится к
инструменту. Для части приставки инструментальных имен верхний уровень
указывает на тип инструмента.
Часть суффикса инструментальных имен прибывает непосредственно из кода для
инструментов. Суффиксы могут включать уровни, такие как:
Название главного компонента (модуль сервера такой, как
myisam, innodb,
mysys или sql) или имя плагина. - Название переменной в коде, в форме
XXX (глобальная переменная) или
CCC::MMMMMM класса CCC). Примеры:
COND_thread_cache, THR_LOCK_myisam,
BINLOG::LOCK_index.
Высокоуровневые инструментальные компоненты
Неактивные инструментальные компоненты
Инструмент idle используется для неактивных событий, которые
Performance Schema производит как обсуждено в описании столбца
socket_instances.STATE в
разделе 23.9.3.5.
Ошибочные инструментальные компоненты
Инструмент error указывает, собрать ли информацию для ошибок
сервера и предупреждений. Этот инструмент включен по умолчанию. Столбец
TIMED для строки error в
setup_instruments
является неподходящим, потому что информация синхронизации не собрана.
Инструментальные компоненты памяти
Большинство инструментов памяти отключено по умолчанию и может быть
включено или отключено динамически, обновляя столбец
ENABLED соответствующих инструментов в
setup_instruments
. У инструментов памяти есть названия формы
memory/code_area/instrument_name
, где code_area такое значение, как
sql или myisam, а
instrument_name инструментальная деталь.
Инструменты с приставкой memory/performance_schema/
показывают, сколько памяти выделено для внутренних буферов в Performance
Schema. Инструменты memory/performance_schema/ встроены, всегда
включаются, и не могут быть отключены при запуске или во время выполнения.
Встроенные инструменты памяти выведены на экран только в таблице
memory_summary_global_by_event_name.
Инструментальные компоненты этапа
У инструментов этапа есть названия формы
stage/code_area/stage_name
, где code_area такое значение, как
sql или myisam, а stage_name
указывает на этап обработки запроса, такой как Sorting result
или Sending data. Этапы соответствуют статусам потока,
выведенным на экран SHOW
PROCESSLIST или видимым в
INFORMATION_SCHEMA.PROCESSLIST
.
Инструментальные Компоненты запроса
statement/abstract/*: Абстрактный инструмент для
операций запроса. Абстрактные инструменты используются во время ранних стадий
классификации запроса прежде, чем точный тип запроса будет известен, затем
изменены на более определенный инструмент запроса, когда тип известен. Для
описания этого процесса см.
раздел 23.9.6.
statement/com: Инструментованная работа команды. У них есть
соответствие имен COM_xxx
(см. файлы mysql_com.h и sql/sql_parse.cc).
Например, инструменты statement/com/Connect и
statement/com/Init DB соответствуют командам
COM_CONNECT и COM_INIT_DB.statement/scheduler/event: Единственный инструмент, чтобы
отследить все события, запущенные планировщиком событий. Этот инструмент
играет роль, когда запланированный случай начинает выполняться.statement/sp: Инструментованная внутренняя инструкция
выполнена сохраненной программой. Например, инструменты
statement/sp/cfetch и statement/sp/freturn
применяются для получения курсора и возврата из функции.statement/sql: Инструментованная работа запроса SQL.
Например, инструменты statement/sql/create_db и
statement/sql/select используются для
CREATE DATABASE и
SELECT.
Инструментальные компоненты ожидания
wait/io
Инструментованная работа ввода/вывода.
wait/io/file
Инструментованная работа ввода/вывода файла. Для файлов ожидание
является временем ожидания завершения работы файла (например, вызов
fwrite()). Из-за кэширования физический ввод/вывод файла на
диске не может произойти в пределах этого требования. wait/io/socket
Инструментованная работа сокета. У инструментов сокета есть названия формы
wait/io/socket/sql/socket_type. У сервера
есть сокеты для каждого сетевого протокола, который он поддерживает. У
инструментов, связанных с сокетами TCP/IP или соединений файла сокета Unix,
есть значение socket_type
server_tcpip_socket или server_unix_socket,
соответственно. Когда сокет слушания обнаруживает соединение, сервер передает
соединение с новым сокетом, которым управляет отдельный поток. У инструмента
для нового потока соединения есть значение
socket_type client_connection. wait/io/table
Инструментованная табличная работа ввода/вывода. Они включают доступы на
уровне строки к постоянным базовым или временным таблицам. Операции, которые
затрагивают строки, являются получением, вставками, обновлениями и удалениями.
Для представления ожидание связано с базовыми таблицами, на
которые ссылается представление.
В отличие от большинства ожиданий, табличный ввод/вывод может включать
другое ожидание. Например, табличный ввод/вывод мог бы включать ввод/вывод
файла или операции памяти. Таким образом,
events_waits_current
для таблицы обычно имеет две строки.
Некоторые операции строки могли бы вызвать многократный табличный
ввод/вывод. Например, вставка могла бы активировать триггер,
который вызывает обновление.
wait/lock
Инструментованная работа блокировки.
wait/synch
Инструментованный объект синхронизации. Для объектов синхронизации
время TIMER_WAIT включает количество заблокированное времени,
потраченное пытаясь приобрести блокировку на объекте, если это было.
wait/synch/cond
Условие используется одним потоком, чтобы сигнализировать другим потокам,
что что-то, чего они ждали, произошло. Если единственный поток ждал условия,
он может проснуться и возобновить выполнение. Если несколько потоков ждали,
они могут все проснуться и конкурировать за ресурс, которого они ждали. wait/synch/mutex
Объект взаимного исключения используется, чтобы разрешить доступ к ресурсу
(такому, как раздел выполнимого кода), препятствуя другим потокам
получить доступ к ресурсу. wait/synch/rwlock
Объект блокировки чтения-записи
используется, чтобы блокировать определенную переменную для доступа,
предотвращая ее использование другими потоками. Совместно используемая
блокировка чтения может быть приобретена одновременно многими потоками.
Исключительная блокировка записи может быть приобретена только одним потоком
за один раз. wait/synch/sxlock
Совместно используемо-исключительная (SX) блокировка тип объекта
блокировки rwlock, который
обеспечивает доступ на запись к общему ресурсу, разрешая непоследовательные
чтения другим потокам.
23.5.
Контроль состояния Performance Schema
Есть несколько переменных состояния, связанных с Performance Schema:
mysql> SHOW STATUS LIKE 'perf%';
+-----------------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------------+-------+
| Performance_schema_accounts_lost | 0 |
| Performance_schema_cond_classes_lost | 0 |
| Performance_schema_cond_instances_lost | 0 |
| Performance_schema_digest_lost | 0 |
| Performance_schema_file_classes_lost | 0 |
| Performance_schema_file_handles_lost | 0 |
| Performance_schema_file_instances_lost | 0 |
| Performance_schema_hosts_lost | 0 |
| Performance_schema_locker_lost | 0 |
| Performance_schema_memory_classes_lost | 0 |
| Performance_schema_metadata_lock_lost | 0 |
| Performance_schema_mutex_classes_lost | 0 |
| Performance_schema_mutex_instances_lost | 0 |
| Performance_schema_nested_statement_lost | 0 |
| Performance_schema_program_lost | 0 |
| Performance_schema_rwlock_classes_lost | 0 |
| Performance_schema_rwlock_instances_lost | 0 |
| Performance_schema_session_connect_attrs_lost | 0 |
| Performance_schema_socket_classes_lost | 0 |
| Performance_schema_socket_instances_lost | 0 |
| Performance_schema_stage_classes_lost | 0 |
| Performance_schema_statement_classes_lost | 0 |
| Performance_schema_table_handles_lost | 0 |
| Performance_schema_table_instances_lost | 0 |
| Performance_schema_thread_classes_lost | 0 |
| Performance_schema_thread_instances_lost | 0 |
| Performance_schema_users_lost | 0 |
+-----------------------------------------------+-------+
Переменные состояния Performance Schema предоставляют информацию об
инструментовке, которая не могла быть загружена или создана из-за ограничений
памяти. У названий этих переменных есть несколько форм:
Например, если mutex инструментован в источнике сервера, но сервер не
может выделить память для инструментовки во время выполнения, это увеличивает
Performance_schema_mutex_classes_lost. Здесь mutex все еще
функционирует как объект синхронизации (то есть, сервер продолжает
функционировать обычно), но характеристики для этого не будут собраны. Если
инструмент может быть выделен, он может использоваться для того, чтобы
инициализировать инструментованные mutex случаи. Для единичного mutex, такого
как глобальный mutex, будет только один случай. У других mutex есть случай на
соединение или страницу в различных кэшах и буферах данных, таким образом,
число случаев изменяется в течение долгого времени. Увеличение максимального
количества соединений или максимального размера некоторых буферов увеличит
максимальное количество случаев, которые могли бы быть выделены сразу. Если
сервер не может создать инструментованный mutex случай, он увеличивает
Performance_schema_mutex_instances_lost.
Предположите, что следующие условия выполнены:
Сервер выделяет mutex инструменты для плагинов в зависимости от того,
в скольких они нуждаются и сколько доступно, как иллюстрировано
следующей последовательностью запросов:
INSTALL PLUGIN plugin_a
Сервер теперь имеет 150+40 = 190 mutex.
UNINSTALL PLUGIN plugin_a;
У сервера все еще есть 190 инструментов. Все исторические данные,
произведенные сменным кодом, являются все еще доступными, но новые события
для инструментов не собраны.
INSTALL PLUGIN plugin_a;
Сервер обнаруживает, что эти 40 инструментов уже определены,
таким образом, никакие новые инструменты не создаются, и ранее назначенные
внутренние буферы памяти снова использованы.
У сервера все еще есть 190 инструментов.
INSTALL PLUGIN plugin_b;
Сервер имеет пространство для 200-190 = 10 инструментов (в этом случае
классы mutex) и видит, что плагин содержит 20 новых инструментов. 10
инструментов загружены, а 10 потеряны.
Performance_schema_mutex_classes_lost указывает на
число потерянных инструментов:
mysql> SHOW STATUS LIKE "perf%mutex_classes_lost";
+---------------------------------------+-------+
| Variable_name | Value |
+---------------------------------------+-------+
| Performance_schema_mutex_classes_lost | 10 |
+---------------------------------------+-------+
1 row in set (0.10 sec)
Инструментовка все еще работает и собирает (частичные) данные для
plugin_b.
Когда сервер не может создать mutex инструмент, эти результаты происходят:
Этот пример относится ко всем типам инструментов, не только mutex.
Значение
Performance_schema_mutex_classes_lost больше 0
может произойти в двух случаях:
Чтобы сохранить несколько байтов памяти, Вы запускаете сервер с
--performance_schema_max_mutex_classes=N,
где N меньше, чем значение по умолчанию. Значение по
умолчанию выбрано, чтобы быть достаточным, чтобы загрузить все плагины,
обеспеченные в дистрибутиве MySQL, но это может быть уменьшено, если
некоторые плагины никогда не загружаются. Например, Вы могли бы хотеть не
загружать некоторые из механизмов хранения. - Вы загружаете имеющий отношение к третьей стороне плагин, который
инструментован для Performance Schema, но не учитываете требования к памяти
инструментовки плагина, когда Вы запускаете сервер. Поскольку это прибывает
от третьей стороны, инструментальное потребление памяти этого механизма не
составляется в значении по умолчанию, выбранном для
performance_schema_max_mutex_classes.
Если у сервера недостаточно ресурсов для инструментов плагина, и Вы
явно не выделяете больше, используя
--performance_schema_max_mutex_classes=N,
загрузка плагина приводит к проблемам.
Если значение, выбранное для
performance_schema_max_mutex_classes является слишком маленьким,
ни о какой ошибке не сообщают в журнале ошибок и нет никакого отказа во время
выполнения. Однако, контент таблиц в performance_schema
пропустит события. Переменная состояния
Performance_schema_mutex_classes_lost единственный видимый
знак указать, что некоторые события были удалены внутренне из-за
отказа создать инструменты.
Если инструмент не потерян, он известен Performance Schema
и используется, инструментуя случаи. Например,
wait/synch/mutex/sql/LOCK_delete имя mutex инструмента в
setup_instruments
. Этот единственный инструмент используется, создавая mutex в коде (в
THD::LOCK_delete), однако, много случаев mutex необходимы, когда
сервер работает. В этом случае LOCK_delete mutex для соединения
(THD), так что, если у сервера есть 1000 соединений, есть 1000
потоков и 1000 инструментованных случаев LOCK_delete mutex
(THD::LOCK_delete).
Если сервер не имеет пространства для инструментованного mutexes всех
этих 1000, некоторые mutex создаются с инструментовкой, а некоторые создаются
без инструментовки. Если сервер может создать только 800 случаев, 200 случаев
потеряны. Сервер продолжает работать, но увеличивает
Performance_schema_mutex_instances_lost на 200, чтобы указать, что
случаи не могли быть созданы.
Значение
Performance_schema_mutex_instances_lost больше 0
может произойти, когда код инициализирует больше mutex во время выполнения,
чем было выделено для
--performance_schema_max_mutex_instances=N.
-Нижняя строка это если
SHOW STATUS LIKE 'perf%'
говорит, что ничто не было потеряно (все значения - ноль), Исполнительные
данные точны и могут быть использованы. Если что-то было потеряно, данные
неполные, и Performance Schema не могла сделать запись всех данных.
В этом случае переменная Performance_schema_xxx
_lost указывает на проблемную область.
Могло бы быть уместно в некоторых случаях вызвать преднамеренный
инструментальный сбой. Например, если Вы не заботитесь о характеристиках
ввода/вывода файла, Вы можете запустить сервер со всеми параметрами
Performance Schema, связанных с вводом/выводом файла, установленными в 0.
Никакая память не будет выделена для связанных с файлом классов, случаев
или дескрипторов, и все события файла будут потеряны.
Надо использовать SHOW ENGINE
PERFORMANCE_SCHEMA STATUS, чтобы просмотреть внутреннюю работу
кода Performance Schema:
mysql> SHOW ENGINE PERFORMANCE_SCHEMA STATUS\G
...
*************************** 3. row ***************************
Type: performance_schema
Name: events_waits_history.size
Status: 76
*************************** 4. row ***************************
Type: performance_schema
Name: events_waits_history.count
Status: 10000
*************************** 5. row ***************************
Type: performance_schema
Name: events_waits_history.memory
Status: 760000
...
*************************** 57. row ***************************
Type: performance_schema
Name: performance_schema.memory
Status: 26459600
...
Это запрос предназначен, чтобы помочь DBA понять эффекты, которые
различные опции Performance Schema оказывают на требования к памяти. Для
описания полевых значений см.
раздел 14.7.5.15.
23.6.
События атома и молекулы Performance Schema
Для табличного случая ввода/вывода обычно есть две строки в
events_waits_current
. Например, получение строки могло бы привести к строкам как эти:
Row# EVENT_NAME TIMER_START TIMER_END
---- ---------- ----------- ---------
1 wait/io/file/myisam/dfile 10001 10002
2 wait/io/table/sql/handler 10000 NULL
Получение строки вызывает чтение файла. В примере табличный случай
ввода/вывода запускался перед случаем ввода/вывода файла, но не закончился
(Значение TIMER_END NULL). Случай ввода/вывода
файла вложен в пределах табличного случая ввода/вывода.
Это происходит, потому что, в отличие от атомного события
(mutex или ввода/вывода файла), табличные события ввода/вывода
молекулярные и включают (перекрывают) другие события. В
In events_waits_current
у табличного случая ввода/вывода обычно есть две строки:
Обычно, но не всегда, случай ожидания отличается от табличного
случая ввода/вывода. Поскольку каждый вспомогательный случай завершается, он
исчезает из
events_waits_current. В этом пункте, пока начинается следующий
вспомогательный случай, табличный ввод/вывод также новее
ожидания любого вида.
23.7.
Обзоры запроса Performance Schema
Сервер MySQL способен к поддержанию информации об обзоре запроса.
Процесс переваривания преобразовывает запрос SQL к нормализованной форме и
вычисляет значение хеша для результата. Нормализация разрешает запросы,
которые подобны, сгруппировать и суммировать, чтобы выставить информацию о
типах запросов, которые выполняет сервер и то, как часто они происходят.
Этот раздел описывает, как нормализация запросы происходит и как это
может быть полезно.
Переваривание происходит на уровне SQL независимо от того, доступна ли
Performance Schema, чтобы у других функций сервера, таких как плагины
перезаписи запроса был доступ к обзорам запроса.
В Performance Schema запрос вовлекает эти компоненты:
Потребитель statement_digest в
setup_consumers
управляет, поддерживает ли Performance Schema информацию об обзоре. - Таблицы запроса событий
(
events_statements_current,
events_statements_history и
events_statements_history_long) имеют столбцы, которые содержат
обзоры и соответствующие значения хеша обзора:
Максимальное пространство, доступное для вычисления обзора, составляет
1024 байта по умолчанию. Это значение может быть изменено при запуске
сервера, устанавливая переменную
performance_schema_max_digest_length.
- У таблиц запроса событий также есть столбец
SQL_TEXT,
который содержит оригинальный запрос SQL. Максимальное пространство,
доступное для отображнеия запроса, составляет 1024 байта по умолчанию. Это
значение может быть изменено при запуске сервера, устанавливая переменную
performance_schema_max_sql_text_length.
- Таблица
events_statements_summary_by_digest предоставляет соединенную
информацию об обзоре запроса.
Нормализация преобразовывает текст запроса к более стандартизированному
строковому представлению обзора, которое сохраняет структуру общего
утверждения, удаляя информацию, не важную для структуры:
Рассмотрите эти запросы:
SELECT * FROM orders WHERE customer_id=10 AND quantity > 20
SELECT * FROM orders WHERE customer_id = 20 AND quantity > 100
Чтобы нормализовать эти запросы, Performance Schema
заменяет значения данных ? и корректирует пробелы.
Оба запроса приводят к той же самой нормализованной форме и таким
образом считаются подобными:
SELECT * FROM orders WHERE customer_id = ? AND quantity > ?
Нормализованный запрос содержит меньше информации, но является все еще
представительным для оригинального запроса. У других подобных запросов,
у которых есть различные сравнительные значения, есть та же
самая нормализованная форма.
Теперь рассмотрите эти запросы:
SELECT * FROM customers WHERE customer_id = 1000
SELECT * FROM orders WHERE customer_id = 1000
В этом случае запросы не подобны. Идентификаторы объекта
отличаются, таким образом, запросы приводят к
различным нормализованным формам:
SELECT * FROM customers WHERE customer_id = ?
SELECT * FROM orders WHERE customer_id = ?
Если нормализация производит запрос, который превышает пространство,
доступное в буфере обзора, текст кончается с ....
Длинные запросы, которые отличаются только по части, которая происходит после
..., как полагают, являются подобными. Рассмотрите эти запросы:
SELECT * FROM mytable WHERE cola = 10 AND colb = 20
SELECT * FROM mytable WHERE cola = 10 AND colc = 20
Если сокращение было правильным, после AND
у обоих запросов была бы эта нормализованная форма:
SELECT * FROM mytable WHERE cola = ? AND ...
В этом случае различие во втором имени столбца потеряно, и
оба запросы считаются подобными.
Для каждого нормализованного запроса Performance Schema
вычисляет значение обзора хеша и хранит запрос и его значение хеша MD5 в
столбцах DIGEST_TEXT и DIGEST таблиц событий
запросов (
events_statements_current,
events_statements_history и
events_statements_history_long). Кроме того, информация для
запросов с теми же самыми значениями SCHEMA_NAME и
DIGEST соединена в таблице
events_statements_summary_by_digest. Performance Schema использует
значения хеша MD5, потому что они быстры, чтобы вычислить и иметь
благоприятное статистическое распределение,
которое минимизирует столкновения.
Сводная таблица обзора запросов обеспечивает профиль запросов, выполненных
сервером. Это показывает, какие виды запросов приложение выполняет и как
часто. Разработчик приложений может использовать эту информацию вместе с
другой информацией в таблице, чтобы оценить технические характеристики
приложения. Например, столбцы таблицы, которые показывают время ожидания,
время блокировки или использование индекса, могут выделить типы запросов,
которые неэффективны. Это дает понимание разработчика, каким частям
приложения необходимо уделять внимание.
events_statements_summary_by_digest имеет фиксированный размер,
так что, когда это становится полным, запросы, которые имеют
SCHEMA_NAME и DIGEST не соответствующие
существующим значениям в таблице, сгруппированы в специальной строке с
SCHEMA_NAME и DIGEST NULL.
Это разрешает всем запросым быть посчитанными. Однако, если специальная
строка составляет существенный процент выполненных запросов, могло бы быть
желательно увеличить размер сводной таблицы, устанавливая переменную
performance_schema_digests_size к большему значению при запуске
сервера. Если не задано значение
performance_schema_digests_size, Performance Schema использует
значение при запуске.
Переменная
performance_schema_max_digest_length определяет максимальное
количество байтов, доступных в буфере обзора для вычисления обзора.
Однако, длина отображения обзоров может быть больше, чем доступный размер
буфера из-за кодирования компонентов запросы, таких как ключевые слова и
буквальные значения в буфере обзора. Следовательно, значения, выбранные из
столбца DIGEST_TEXT таблиц событий запросов, может казаться,
превышает
performance_schema_max_digest_length.
Для приложений, которые производят очень длинные запросы, которые
отличаются только в конце, увеличение
performance_schema_max_digest_length позволяет вычисление
обзоров, которые отличают запросы, которые иначе соединились бы к тому же
самому обзору. Наоборот, уменьшение
performance_schema_max_digest_length
заставляет сервер посвящать меньше памяти хранению обзора, но увеличивает
вероятность более длинных запросов, соединяющихся к тому же самому обзору.
Администраторы должны иметь в виду, что большие значения приводят к
соответственно увеличенным требованиям к памяти, особенно для рабочих
нагрузок, которые вовлекают большие количества одновременных сеансов
(
performance_schema_max_digest_length байт выделено на сеанс).
Чтобы оценить объем памяти, используемый для хранения запроса SQL
и вычисления обзора, используйте SHOW ENGINE PERFORMANCE_SCHEMA STATUS
или эти инструменты:
mysql> SELECT NAME FROM setup_instruments
WHERE NAME LIKE '%.sqltext';
+------------------------------------------------------------------+
| NAME |
+------------------------------------------------------------------+
| memory/performance_schema/events_statements_history.sqltext |
| memory/performance_schema/events_statements_current.sqltext |
| memory/performance_schema/events_statements_history_long.sqltext |
+------------------------------------------------------------------+
mysql> SELECT NAME FROM setup_instruments
WHERE NAME LIKE 'memory/performance_schema/%.tokens';
+----------------------------------------------------------------------+
| NAME |
+----------------------------------------------------------------------+
| memory/performance_schema/events_statements_history.tokens |
| memory/performance_schema/events_statements_current.tokens |
| memory/performance_schema/events_statements_summary_by_digest.tokens |
| memory/performance_schema/events_statements_history_long.tokens |
+----------------------------------------------------------------------+
23.8.
Общие табличные характеристики Performance Schema
Название базы данных performance_schema в
нижнем регистре, как названия таблиц в пределах этого. Запросы должны
определить имена в нижнем регистре.
Много таблиц в performance_schema
только для чтения и не могут быть изменены:
mysql> TRUNCATE TABLE setup_instruments;
ERROR 1683 (HY000): Invalid performance_schema usage.
У некоторых из таблиц установки есть столбцы, которые могут быть изменены,
чтобы затронуть работу Performance Schema. Некоторые также разрешают строкам
быть вставленными или удаленными. Усечение разрешено для очистки собранных
событий, таким образом, TRUNCATE TABLE
может использоваться на таблицах, содержащих эти виды информации,
такие как таблицы, названные с приставкой events_waits_.
Сводные таблицы могут быть усечены с
TRUNCATE TABLE.
Вообще, эффект состоит в том, чтобы сбросить сводные столбцы к 0 или
NULL, а не удалить строки. Это позволяет очистить собранные
значения. Это могло бы быть полезно, например, после того, как Вы произвели
изменение конфигурации во время выполнения. Исключения к этому поведению
усечения отмечены в отдельных разделах сводной таблицы.
Привилегии что касается других баз данных и таблиц:
23.9.
Описания таблиц Performance Schema
Таблицы в performance_schema могут быть
сгруппированы следующим образом:
Таблицы установки. Эти таблицы используются, чтобы
сконфигурировать и вывести на экран контролирующие характеристики. - Таблицы текущих событий.
events_waits_current
содержит новый случай для каждого потока. Другие подобные таблицы
содержат текущие события на разных уровнях иерархии событий:
events_stages_current
для событий этапа,
events_statements_current для событий запросов и
events_transactions_current для операционных событий.
- Таблицы истории. Эти таблицы имеют ту же самую структуру как таблицы
текущих событий, но содержат больше строк. Например, для события ожидания
events_waits_history
содержит новые 10 событий для потока.
events_waits_history_long содержит новые 10000 событий. Другие
подобные таблицы существуют для этапа, запросов и операционных историй.
Чтобы изменить размеры таблиц истории, установите соответствующие
системные переменные при запуске сервера. Например, чтобы установить размеры
таблиц истории ожидания событий, установите
performance_schema_events_waits_history_size и
performance_schema_events_waits_history_long_size.
- Сводные таблицы. Эти таблицы содержат информацию, соединенную по группам
событий, включая те, от которых отказались в таблицах истории.
- Таблицы случая. Эти таблицы документируют, какие типы объектов
инструментованы. Инструментованный объект, когда используется сервером,
производит случай. Эти таблицы обеспечивают имена событий и примечания
или информацию о статусе.
- Разные таблицы. Они не попадают ни в одну из других табличных групп.
23.9.1. Индекс таблиц
Performance Schema
Следующая таблица приводит каждую таблицу Performance Schema
и обеспечивает краткое описание каждой.
Таблица 23.1.
Таблицы Performance Schema
23.9.2.
Таблицы установки Performance Schema
Таблицы установки предоставляют информацию о текущей инструментовке и
позволяют контролирующей конфигурации быть измененной. Поэтому некоторые
столбцы в этих таблицах могут быть изменены, если Вы имеете привилегию
UPDATE.
Использование таблиц, а не отдельных переменных для информации об
установке обеспечивает высокую степень гибкости в изменении конфигурации
Performance Schema. Например, Вы можете использовать единственный запрос со
стандартным синтаксисом SQL, чтобы произвести многократные
одновременные изменения конфигурации.
Эти таблицы установки доступны:
23.9.2.1. Таблица setup_actors
Таблица setup_actors
содержит информацию, которая определяет, позволить ли контролировать и
журналировать исторические события для новых потоков сервера переднего плана
(потоки, связанные с соединениями клиента). У этой таблицы есть максимальный
размер 100 строк по умолчанию. Чтобы изменить табличный размер,
измените системную переменную
performance_schema_setup_actors_size при запуске сервера.
Для каждого нового потока переднего плана Performance Schema
соответствует пользователю и узлу в строке таблицы
setup_actors.
Если строка этой таблицы соответствует, значения ее столбцов
ENABLED и HISTORY используются, чтобы установить
столбцы INSTRUMENTED и HISTORY, соответственно,
в строках таблицы threads
для потока. Это позволяет управлять инструментовкой и журналированием
исторических событий, которое будет применено выборочно для узла,
пользователя или учетной записи (комбинация узла и пользователя). Если нет
соответствия, INSTRUMENTED и HISTORY
для потока установлены в NO.
Для фоновых потоков нет никакого связанного пользователя.
INSTRUMENTED и HISTORY YES
по умолчанию и setup_actors
не проверяется.
Начальное содержание
setup_actors соответствует любой комбинации пользователя и узла,
таким образом контроль и сбор исторических событий включены по умолчанию для
всех потоков переднего плана:
mysql> SELECT * FROM setup_actors;
+------+------+------+---------+---------+
| HOST | USER | ROLE | ENABLED | HISTORY |
+------+------+------+---------+---------+
| % | % | % | YES | YES |
+------+------+------+---------+---------+
Модификации setup_actors
вступают в силу только при создании потоков переднего плана
после модификации, на существующие потоки изменения не влияют.
Чтобы затронуть существующие потоки, измените столбцы
INSTRUMENTED и HISTORY строк таблицы
threads.
У таблицы setup_actors
есть эти столбцы:
HOST
Имя хоста. Это должно быть буквальным именем или
'%' означает любой хост. USER
Имя пользователя. Это должно быть буквальным именем или
'%' означает любой пользователь. ROLE
Не используется. ENABLED
Включить ли инструментовку для потоков переднего плана, соответствующих
строке. Значения YES или NO. HISTORY
Зарегистрировать ли исторические события для потоков переднего плана,
соответствующих строке. Значения YES или NO.
У таблицы setup_actors
есть эти индексы:
TRUNCATE TABLE
разрешен для setup_actors
. Удаляет строки.
23.9.2.2. Таблица setup_consumers
Таблица setup_consumers
приводит типы потребителей, для которых может быть сохранена
информация о событии и которые включены:
mysql> SELECT * FROM setup_consumers;
+----------------------------------+---------+
| NAME | ENABLED |
+----------------------------------+---------+
| events_stages_current | NO |
| events_stages_history | NO |
| events_stages_history_long | NO |
| events_statements_current | YES |
| events_statements_history | YES |
| events_statements_history_long | NO |
| events_transactions_current | NO |
| events_transactions_history | NO |
| events_transactions_history_long | NO |
| events_waits_current | NO |
| events_waits_history | NO |
| events_waits_history_long | NO |
| global_instrumentation | YES |
| thread_instrumentation | YES |
| statements_digest | YES |
+----------------------------------+---------+
Модификации
setup_consumers действуют немедленно.
У таблицы
setup_consumers есть эти столбцы:
У setup_consumers
есть эти индексы:
TRUNCATE TABLE
не разрешен для
setup_consumers.
23.9.2.3. Таблица setup_instruments
setup_instruments
приводит классы инструментованных объектов, для которых могут
быть собраны события:
mysql> SELECT * FROM setup_instruments;
+---------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+---------------------------------------------------+---------+-------+
...
| wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES |
| wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES |
| wait/synch/mutex/sql/LOCK_lock_db | YES | YES |
| wait/synch/mutex/sql/LOCK_manager | YES | YES |
...
| wait/synch/rwlock/sql/LOCK_grant | YES | YES |
| wait/synch/rwlock/sql/LOGGER::LOCK_logger | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_connect | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_slave | YES | YES |
...
| wait/io/file/sql/binlog | YES | YES |
| wait/io/file/sql/binlog_index | YES | YES |
| wait/io/file/sql/casetest | YES | YES |
| wait/io/file/sql/dbopt | YES | YES |
...
Каждый инструмент, добавленный к исходному коду, обеспечивает строку
в этой таблице, даже когда инструментованный код не выполнен. Когда
инструмент включен и запущен, инструментованные случаи создаются, которые
видимы в таблицах *_instances.
Для некоторых инструментов модификации эффективны только при запуске
сервера, изменение их во времени выполнения не имеет никакого эффекта. Это
затрагивает прежде всего mutex, условия и rwlocks в сервере, хотя могут быть
другие инструменты, для которых это истина. Для большинства изменения
вступают в силу сразу.
У setup_instruments
есть эти столбцы:
NAME
Инструментальное имя. Инструментальные имена могут иметь много частей
и сформировать иерархию, как обсуждено в
разделе 23.4.
События, произведенные из выполнения инструмента, имеют
EVENT_NAME, которое взято от инструментального значения
NAME. У событий действительно нет name,
но это обеспечивает способ связать события с инструментами. ENABLED
Включен ли инструмент. Значение YES или NO.
Этот столбец может быть изменен.
Отключенный инструмент не производит событий. TIMED
Рассчитан ли инструмент. Этот столбец может быть изменен.
Для инструментов памяти столбец TIMED в
setup_instruments
проигнорирован, потому что операции памяти не рассчитаны.
Если включенный инструмент не рассчитан, инструментальный код включен,
но таймер нет. События, произведенные инструментом, имеют NULL
для TIMER_START, TIMER_END и
TIMER_WAIT. Это в свою очередь заставляет те значения быть
проигнорированными, вычисляя сумму, минимум, максимум и средние временные
оценки в сводных таблицах.
У setup_instruments
есть эти индексы:
TRUNCATE TABLE не
разрешен для
setup_instruments.
23.9.2.4. Таблица setup_objects
setup_objects
управляет, контролирует ли Performance Schema особые объекты. У этой таблицы
есть максимальный размер 100 строк по умолчанию. Чтобы изменить табличный
размер, измените переменную
performance_schema_setup_objects_size при запуске сервера.
Начальное содержание
setup_objects похоже на это:
mysql> SELECT * FROM setup_objects;
+-------------+--------------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED |
+-------------+--------------------+-------------+---------+-------+
| EVENT | mysql | % | NO | NO |
| EVENT | performance_schema | % | NO | NO |
| EVENT | information_schema | % | NO | NO |
| EVENT | % | % | YES | YES |
| FUNCTION | mysql | % | NO | NO |
| FUNCTION | performance_schema | % | NO | NO |
| FUNCTION | information_schema | % | NO | NO |
| FUNCTION | % | % | YES | YES |
| PROCEDURE | mysql | % | NO | NO |
| PROCEDURE | performance_schema | % | NO | NO |
| PROCEDURE | information_schema | % | NO | NO |
| PROCEDURE | % | % | YES | YES |
| TABLE | mysql | % | NO | NO |
| TABLE | performance_schema | % | NO | NO |
| TABLE | information_schema | % | NO | NO |
| TABLE | % | % | YES | YES |
| TRIGGER | mysql | % | NO | NO |
| TRIGGER | performance_schema | % | NO | NO |
| TRIGGER | information_schema | % | NO | NO |
| TRIGGER | % | % | YES | YES |
+-------------+--------------------+-------------+---------+-------+
Модификации действуют немедленно.
Для типов объекта, перечисленных в
setup_objects,
Performance Schema использует таблицу для того, как контролировать их.
Соответствие лбъектов основано на столбцах OBJECT_SCHEMA и
OBJECT_NAME. Объекты, которые не идут ни в какое
сравнение, не проверены.
Эффект конфигурации объекта по умолчанию состоит в том, чтобы
инструментовать все таблицы кроме в
mysql, INFORMATION_SCHEMA и
performance_schema. Таблицы в INFORMATION_SCHEMA
не инструментована независимо от содержания
setup_objects.
Строка information_schema.% просто делает это значение явным.
Когда Performance Schema checks проверяет на соответствие
setup_objects,
это пытается найти более определенные соответствия сначала. Например, с
таблицей db1.t1, это ищет совпадение для
'db1' и 't1', потом для
'db1' и '%', потом для
'%' и '%'. Порядок, в котором соответствие
происходит таков, потому что различные строки
setup_objects
могут иметь отличающиеся ENABLED и TIMED.
Строки могут быть вставлены или удалены из
setup_objects
пользователями с привилегиями
INSERT или DELETE
на таблице. Для существующих строк могут быть изменены только
столбцы ENABLED и TIMED пользователями с
привилегией UPDATE.
У setup_objects
есть эти столбцы:
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
есть эти индексы:
TRUNCATE TABLE
разрешен для setup_objects
. Это удаляет строки.
23.9.2.5. Таблица setup_timers
setup_timers
показывает в настоящее время выбираемые таймеры событий:
mysql> SELECT * FROM setup_timers;
+-------------+-------------+
| NAME | TIMER_NAME |
+-------------+-------------+
| idle | MICROSECOND |
| wait | CYCLE |
| stage | NANOSECOND |
| statement | NANOSECOND |
| transaction | NANOSECOND |
+-------------+-------------+
setup_timers.TIMER_NAME может быть изменено, чтобы выбрать
иной таймер. Значение может быть любым из значений в столбце
performance_timers.TIMER_NAME.
Изменения в setup_timers
действуют немедленно. События, уже происходящие, могут
использовать оригинальный таймер в начале и новый таймер в конце. Чтобы
избежать непредсказуемых результатов после того, как Вы производите изменения
таймера, надо использовать
TRUNCATE TABLE для сброса
статистики Performance Schema.
У setup_timers
есть эти столбцы:
NAME
Тип инструмента, для которого таймер используется. TIMER_NAME
Таймер, который относится к инструментальному типу.
Этот столбец может быть изменен.
У setup_timers
есть эти индексы:
TRUNCATE TABLE не
позволен для setup_timers
.
23.9.3.
Таблицы случая Performance Schema
Таблицы случая документируют, какие типы объектов инструментованы. Они
обеспечивают имена событий и примечания или информацию о статусе:
Эти таблицы приводят инструментованные объекты синхронизации, файлы и
соединения. Есть три типа объектов синхронизации: cond,
mutex и rwlock. Каждая таблица случая имеет
столбцы EVENT_NAME или NAME, чтобы указать на
инструмент, связанный с каждой строкой. Инструментальные имена могут иметь
много частей и сформировать иерархию, как обсуждено в
разделе 23.4.
Столбцы mutex_instances.LOCKED_BY_THREAD_ID и
rwlock_instances.WRITE_LOCKED_BY_THREAD_ID чрезвычайно важны для
исследования исполнительных узких мест или тупиков. Для примеров того, как
использовать их с этой целью см.
раздел 23.16.
23.9.3.1. Таблица cond_instances
cond_instances
приводит все условия, замеченные Performance Schema в то время, как сервер
выполняется. Условие это механизм синхронизации, используемый в коде, чтобы
сигнализировать, что определенное событие произошло, чтобы поток, ждущий
этого условия, мог возобновить работу.
Когда поток ждет чего-то, имя условия это признак того, чего ждет поток,
но нет никакого непосредственного способа сказать, который другой поток или
потоки вызовет условие.
У cond_instances
есть эти столбцы:
У cond_instances
есть эти индексы:
TRUNCATE TABLE не
позволен для cond_instances
.
23.9.3.2. Таблица file_instances
file_instances
приводит все файлы, замеченные Performance Schema, запуская инструментовку
ввода/вывода файла. Если файл на диске никогда не открывался, его не будет в
file_instances.
Когда файл удален с диска, он также удален из
file_instances.
У file_instances
есть эти столбцы:
FILE_NAME
Имя файла. EVENT_NAME
Инструментальное имя, связанное с файлом. OPEN_COUNT
Количество открытых дескрипторов на файле. Если файл был открыт и затем
закрыт, он был открыт 1 раз, но OPEN_COUNT будет 0. Чтобы
перечислить все файлы, в настоящее время открываемые сервером, надо
использовать WHERE OPEN_COUNT > 0.
У file_instances
есть эти индексы:
TRUNCATE TABLE
не позволен для
file_instances.
23.9.3.3. Таблица mutex_instances
mutex_instances
приводит все mutex, замеченные Performance Schema в то время, как сервер
выполняет. mutex это механизм синхронизации, используемый в коде, чтобы
провести в жизнь только тот поток, который в установленный срок может иметь
доступ к некоторому общему ресурсу. Ресурс, как говорят, при этом
является защищенным mutex.
Когда два потока в сервере (например, два пользовательских сеанса,
выполняющие запрос одновременно), действительно должны будут получить доступ
к тому же самому ресурсу (файлу, буферу или некоторой части данных), эти два
потока конкурируют друг против друга так, чтобы первый запрос, который
получит блокировку на mutex, заставил другой запрос ждать, пока первый не
будет сделан и отпирает mutex.
Это потенциально узкое место, именуемое "критический раздел".
Проблема в том, что много потоков вынуждены проходить его строго
последовательно и по одному.
У mutex_instances
есть эти столбцы:
NAME
Инструментальное имя, связанное с mutex. OBJECT_INSTANCE_BEGIN
Адрес в памяти об инструментованном mutex. LOCKED_BY_THREAD_ID
Когда потоку в настоящее время блокировали mutex,
LOCKED_BY_THREAD_ID THREAD_ID
потока блокировки, иначе это NULL.
У mutex_instances
есть эти индексы:
TRUNCATE TABLE не
позволен для mutex_instances
.
Для каждого mutex, инструментованного в коде, Performance Schema
предоставляет следующую информацию.
Таблица
setup_instruments приводит название пункта инструментовки, с
приставкой wait/synch/mutex/. - Когда некоторый код создает mutex, строка добавлена к таблице
mutex_instances.
Столбец OBJECT_INSTANCE_BEGIN свойство, которое
уникально идентифицирует mutex.
- Когда поток пытается заблокировать mutex,
events_waits_current
показывает строку для этого потока, указывая, что он ждет mutex
(в столбце EVENT_NAME) и указание, какой mutex ждут (в столбце
OBJECT_INSTANCE_BEGIN).
- Когда поток преуспевает в том, чтобы блокировать mutex:
Когда поток отпирает mutex,
mutex_instances
показывает, что у mutex теперь нет никакого владельца
(THREAD_ID NULL). - Когда объект mutex разрушен, соответствующая строка удалена из
mutex_instances.
Выполняя запросы на обеих из следующих таблиц, контролирующее приложение
или DBA могут обнаружить узкие места или тупики между потоками,
которые вовлекают mutex:
23.9.3.4. Таблица rwlock_instances
Таблица rwlock_instances
приводит все rwlock
(read write lock) случаи, замеченные Performance Schema в то время, как
сервер выполняется. rwlock механизм синхронизации, используемый
в коде, чтобы провести в жизнь то, который поток в установленный срок может
иметь доступ к некоторому общему ресурсу по определенным правилам.
Ресурс, как говорят, является защищенным rwlock.
Доступ совместно использован (у многих потоков может быть блокировка чтения в
то же самое время), исключительный (только у одного потока может быть
блокировка записи в установленный срок) или совместно
используемо-исключительный (у потока может быть блокировка записи, разрешая
непоследовательные чтения другими потоками). Совместно используемый
эксклюзивный доступ иначе известен как sxlock и был введен в
MySQL 5.7, чтобы оптимизировать параллелизм и улучшить масштабируемость
для чтения-записи.
В зависимости от того, сколько потоков просят блокировку, и природы
блокировок, которые требуются, доступ можно или предоставить в совместно
используемом режиме, исключительном режиме, совместно
используемо-исключительном режиме или не предоставить вообще, ожидая сначала
завершения других потоков.
У rwlock_instances
есть эти столбцы:
NAME
Инструментальное имя, связанное с блокировкой. OBJECT_INSTANCE_BEGIN
Адрес в памяти об инструментованной блокировке. WRITE_LOCKED_BY_THREAD_ID
Когда поток в настоящее время имеет rwlock заблокированную в
исключительном (записи) режиме, WRITE_LOCKED_BY_THREAD_ID
THREAD_ID потока блокировки, иначе NULL. READ_LOCKED_BY_COUNT
Когда поток в настоящее время имеет rwlock заблокированную в
совместно используемом (чтение) режиме, READ_LOCKED_BY_COUNT
увеличен на 1. Это только счетчик, таким образом, это не может использоваться
непосредственно, чтобы найти, какой поток держит блокировку чтения, но это
может использоваться, чтобы видеть, есть ли чтение на rwlock,
и сколько читателей в настоящее время активно.
У rwlock_instances
есть эти индексы:
TRUNCATE TABLE не
позволен для
rwlock_instances.
Выполняя запросы на обеих из следующих таблиц, контролирующее приложение
или DBA могут обнаружить некоторые узкие места или тупики между потоками,
которые вовлекают блокировки:
Есть ограничение:
rwlock_instances может использоваться только, чтобы
идентифицировать поток, держащий блокировку записи, но не потоки,
держащие блокировку чтения.
23.9.3.5. Таблица socket_instances
socket_instances
обеспечивает снимок в реальном времени активных соединений с сервером
MySQL. Таблица содержит одну строку на TCP/IP или соединение файла сокета
Unix. Информация, доступная в этой таблице, обеспечивает снимок в реальном
времени активных соединений с сервером. Дополнительная информация доступна в
сводных таблицах сокета, включая такую сетевую деятельность, как операции
сокета и число байтов, переданных и полученных, см.
раздел 23.9.15.8).
mysql> SELECT * FROM socket_instances\G
*************************** 1. row ***************************
EVENT_NAME: wait/io/socket/sql/server_unix_socket
OBJECT_INSTANCE_BEGIN: 4316619408
THREAD_ID: 1
SOCKET_ID: 16
IP:
PORT: 0
STATE: ACTIVE
*************************** 2. row ***************************
EVENT_NAME: wait/io/socket/sql/client_connection
OBJECT_INSTANCE_BEGIN: 4316644608
THREAD_ID: 21
SOCKET_ID: 39
IP: 127.0.0.1
PORT: 55233
STATE: ACTIVE
*************************** 3. row ***************************
EVENT_NAME: wait/io/socket/sql/server_tcpip_socket
OBJECT_INSTANCE_BEGIN: 4316699040
THREAD_ID: 1
SOCKET_ID: 14
IP: 0.0.0.0
PORT: 50603
STATE: ACTIVE
У инструментов сокета есть названия формы
wait/io/socket/sql/socket_type
и используются как это:
У сервера есть сокет для каждого сетевого протокола,
который он поддерживает. У инструментов, связанных с сокетами для 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
есть эти индексы:
TRUNCATE TABLE не
позволен для
socket_instances.
Значение комбинации столбца IP:PORT идентифицирует
соединение. Это значение комбинации используется в столбце
the OBJECT_NAME таблицы events_waits_xxx
, чтобы идентифицировать соединение, из которого
прибывают события сокета:
23.9.4.
Таблицы ожидания событий Performance Schema
Эти таблицы хранят ожидание события:
Следующие разделы описывают те таблицы. Есть также сводные таблицы
совокупной информации о событиях ожидания, см.
раздел 23.9.15.1.
Конфигурация событий ожидания
Чтобы включить сбор событий ожидания, включите
соответствующие инструменты и потребителей.
setup_instruments
содержит инструменты с именами, которые
начинаются с wait. Например:
mysql> SELECT * FROM setup_instruments
WHERE NAME LIKE 'wait/io/file/innodb%';
+--------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+--------------------------------------+---------+-------+
| wait/io/file/innodb/innodb_data_file | YES | YES |
| wait/io/file/innodb/innodb_log_file | YES | YES |
| wait/io/file/innodb/innodb_temp_file | YES | YES |
+--------------------------------------+---------+-------+
mysql> SELECT * FROM setup_instruments
WHERE NAME LIKE 'wait/io/socket/%';
+----------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+----------------------------------------+---------+-------+
| wait/io/socket/sql/server_tcpip_socket | NO | NO |
| wait/io/socket/sql/server_unix_socket | NO | NO |
| wait/io/socket/sql/client_connection | NO | NO |
+----------------------------------------+---------+-------+
Чтобы изменить набор событий, изменяют столбцы
ENABLED и TIMING
соответствующих инструментов. Например:
mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME LIKE 'wait/io/socket/sql/%';
setup_consumers
содержит потребительские значения, соответствующие текущим и недавним
именам событий ожидания в таблице. Эти потребители могут использоваться,
чтобы фильтровать события. Потребители отключены по умолчанию:
mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%waits%';
+---------------------------+---------+
| NAME | ENABLED |
+---------------------------+---------+
| events_waits_current | NO |
| events_waits_history | NO |
| events_waits_history_long | NO |
+---------------------------+---------+
Чтобы включить всех потребителей:
mysql> UPDATE setup_consumers SET ENABLED = 'YES'
WHERE NAME LIKE '%waits%';
setup_timers
содержит строку с NAME ожидания, которое
указывает модуль для синхронизации событий.
Модуль по умолчанию CYCLE.
mysql> SELECT * FROM setup_timers WHERE NAME = 'wait';
+------+------------+
| NAME | TIMER_NAME |
+------+------------+
| wait | CYCLE |
+------+------------+
Чтобы изменить модуль синхронизации, измените
значение TIMER_NAME:
mysql> UPDATE setup_timers SET TIMER_NAME = 'NANOSECOND'
WHERE NAME = 'wait';
23.9.4.1.
Таблица events_waits_current
events_waits_current
содержит текущие события ожидания, одна строка на поток,
показывая текущий статус недавно проверенных событий ожидания потока.
Из таблиц, которые содержат строки событий,
events_waits_current
является самой фундаментальной. Другие таблицы, которые содержат
строки событий, логически получены из текущих событий. Например,
events_waits_history
и
events_waits_history_long собирают новые события ожидания до
постоянного числа строк.
У
events_waits_current есть эти столбцы:
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 NULL.
OBJECT_NAME имя файла.OBJECT_TYPE FILE.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 для табличного
ввода/вывода, сокращая количество сообщений о требованиях. Расплата:
меньшая точность для синхронизации событий. А не время для отдельной работы
строки как в сообщении на строку, синхронизация для пакетного ввода/вывода
включает время, проведенное для таких операций, как буферизация соединения,
объединение и возвращение строк клиенту.
Для пакетного ввода/вывода эти условия должны быть истиной:
FLAGS
Сохранено для будущего использования.
У
events_waits_current есть эти индексы:
TRUNCATE TABLE
позволен для
events_waits_current. Это удаляет строки.
23.9.4.2.
Таблица events_waits_history
events_waits_history
содержит новые N событий ожидания на поток.
Значение N автоизмерено при запуске сервера. Чтобы
установить табличный размер явно, установите переменную
performance_schema_events_waits_history_size
при запуске сервера. События не добавлены к таблице, пока они не закончены.
Когда новые события добавлены, от более старых событий отказываются,
если таблица полна.
У
events_waits_history есть та же самая структура, как у
events_waits_current
, включая индексацию. См.
раздел 23.9.4.1.
TRUNCATE TABLE разрешен
для
events_waits_history. Это удаляет строки.
23.9.4.3.
Таблица events_waits_history_long
events_waits_history_long содержит N новых
события ожидания. N определяется при запуске сервера.
Чтобы установить табличный размер явно, установите переменную
performance_schema_events_waits_history_long_size
при запуске сервера. События ожидания не добавлены к таблице, пока они не
закончены. Когда новые события добавлены, от более старых отказываются, если
таблица полна. Когда поток заканчивается, его строки удалены из таблицы.
events_waits_history_long имеет структуру, аналогичную
events_waits_current
, но не имеет индексов. См.
раздел 23.9.4.1.
TRUNCATE TABLE позволен
на
events_waits_history_long. Это удаляет строки.
23.9.5.
Таблицы событий этапа Performance Schema
Инструменты этапа Performance Schema, которые являются шагами во время
процесса выполнения запроса, такими как парсинг запроса, открытие таблицы
или выполнение filesort. Этапы соответствуют статусам,
отображенным SHOW PROCESSLIST
или видимым в таблице
INFORMATION_SCHEMA.PROCESSLIST. Этапы начинаются и заканчиваются,
когда статус оценивает изменение.
Эти таблицы хранят события этапа:
Конфигурация событий этапа
Чтобы включить сбор событий этапа, включите
соответствующие инструменты и потребителей.
setup_instruments
содержит инструменты с именами, которые начинаются с
stage. Кроме тех инструментов, которые предоставляют информацию
о продвижении запроса, эти инструменты отключены по умолчанию. Например:
mysql> SELECT * FROM setup_instruments WHERE NAME RLIKE 'stage/sql/[a-c]';
+----------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+----------------------------------------------------+---------+-------+
| stage/sql/After create | NO | NO |
| stage/sql/allocating local table | NO | NO |
| stage/sql/altering table | NO | NO |
| stage/sql/committing alter table to storage engine | NO | NO |
| stage/sql/Changing master | NO | NO |
| stage/sql/Checking master version | NO | NO |
| stage/sql/checking permissions | NO | NO |
| stage/sql/checking privileges on cached query | NO | NO |
| stage/sql/checking query cache for query | NO | NO |
| stage/sql/cleaning up | NO | NO |
| stage/sql/closing tables | NO | NO |
| stage/sql/Connecting to master | NO | NO |
| stage/sql/converting HEAP to MyISAM | NO | NO |
| stage/sql/Copying to group table | NO | NO |
| stage/sql/Copying to tmp table | NO | NO |
| stage/sql/copy to tmp table | NO | NO |
| stage/sql/Creating sort index | NO | NO |
| stage/sql/creating table | NO | NO |
| stage/sql/Creating tmp table | NO | NO |
+----------------------------------------------------+---------+-------+
Инструменты событий этапа, которые предоставляют информацию о продвижении
запроса, включены и рассчитаны по умолчанию:
mysql> SELECT * FROM setup_instruments WHERE ENABLED='YES' AND
NAME LIKE "stage/%";
+------------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+------------------------------------------------------+---------+-------+
| stage/sql/copy to tmp table | YES | YES |
| stage/innodb/alter table (end) | YES | YES |
| stage/innodb/alter table (flush) | YES | YES |
| stage/innodb/alter table (insert) | YES | YES |
| stage/innodb/alter table (log apply index) | YES | YES |
| stage/innodb/alter table (log apply table) | YES | YES |
| stage/innodb/alter table (merge sort) | YES | YES |
| stage/innodb/alter table (read PK and internal sort) | YES | YES |
| stage/innodb/buffer pool load | YES | YES |
+------------------------------------------------------+---------+-------+
Чтобы изменить набор событий этапа, измените столбцы
ENABLED и TIMING
соответствующих инструментов. Например:
mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME = 'stage/sql/altering table';
setup_consumers
содержит потребительские значения с именами, соответствующими текущим и
недавним именам таблиц этапа событий. Эти потребители могут использоваться,
чтобы фильтровать набор событий этапа.
Потребители этапа отключены по умолчанию:
mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%stages%';
+----------------------------+---------+
| NAME | ENABLED |
+----------------------------+---------+
| events_stages_current | NO |
| events_stages_history | NO |
| events_stages_history_long | NO |
+----------------------------+---------+
Чтобы включить всех потребителей этапа:
mysql> UPDATE setup_consumers SET ENABLED = 'YES'
WHERE NAME LIKE '%stages%';
setup_timers
содержит строку NAME со значением stage, которая
указывает на модуль для синхронизации этапа событий.
Модуль по умолчанию NANOSECOND.
mysql> SELECT * FROM setup_timers WHERE NAME = 'stage';
+-------+------------+
| NAME | TIMER_NAME |
+-------+------------+
| stage | NANOSECOND |
+-------+------------+
Чтобы изменить модуль синхронизации, измените
значение TIMER_NAME:
mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'
WHERE NAME = 'stage';
Информация о продвижении этапа событий
Таблицы событий этапа Performance Schema содержат два столбца, которые,
вместе взятые, обеспечивают индикатор хода выполнения этапа
для каждой строки:
Каждый столбец NULL, если никакая информация о продвижении не
предоставлена для инструмента. Интерпретация информации, если это доступно,
зависит полностью от инструментального выполнения. Таблицы Performance Schema
обеспечивают контейнер, чтобы хранить данные продвижения, но не делают
предположения о семантике метрики непосредственно:
Единица работы является метрикой целого числа,
которая увеличивается в течение долгого времени во время выполнения, такое
как число байтов, строк, файлов или обработанных таблиц. Определение
единицы работы для особого инструмента оставляют коду
инструментовки, обеспечивающему данные. - Значение
WORK_COMPLETED может увеличиться на один
или много модулей за один раз, в зависимости от инструментованного кода.
- Значение
WORK_ESTIMATED может измениться во время этапа, в
зависимости от инструментованного кода.
Инструментовка для индикатора хода выполнения этапа событий может
осуществить любое из следующих поведений:
Никакого прогресса нет.
Это самый типичный случай, где никакие данные о продвижении не обеспечены.
Столбцы WORK_COMPLETED и
WORK_ESTIMATED оба NULL. - Неограниченная инструментовка продвижения.
Только столбец WORK_COMPLETED является значащим. Никакие
данные не предусмотрены для WORK_ESTIMATED,
который выводит на экран 0.
Запрашивая таблицу
events_stages_current для проверенного сеанса, контролирующее
приложение может сообщить, сколько работы до сих пор выполнялось, но не может
сообщить, является ли этап близким к завершению. В настоящее время никакие
этапы не инструментованы таким образом.
- Ограниченная инструментовка продвижения.
Столбцы WORK_COMPLETED и WORK_ESTIMATED
являются оба значащими.
Этот тип индикатора хода выполнения является подходящим для работы с
определенным критерием завершения, таким как инструмент табличной копии,
описанный позже. Запрашивая таблицу
events_stages_current
для проверенного сеанса, контролирующее приложение может
сообщить, сколько работы до сих пор выполнялось, и может сообщить о полном
проценте завершения для этапа, вычисляя коэффициент
WORK_COMPLETED/WORK_ESTIMATED.
Инструмент stage/sql/copy to tmp table иллюстрирует, как
работают индикаторы хода выполнения. Во время выполнения
ALTER TABLE
этап stage/sql/copy to tmp table используется, и этот этап может
выполняться потенциально в течение долгого времени, в зависимости
от размера данных.
У задачи табличной копии есть определенное завершение
(все строки скопированы) и stage/sql/copy to tmp table
инструментован к предоставленной ограниченной информации о продвижении:
используемая единица работы является числом скопированных строк,
WORK_COMPLETED и WORK_ESTIMATED являются значащими,
а их отношение указывает на процент выполнения задачи.
Чтобы включить инструмент и соответствующих потребителей,
выполните эти запросы:
mysql> UPDATE setup_instruments SET ENABLED='YES'
WHERE NAME='stage/sql/copy to tmp table';
mysql> UPDATE setup_consumers SET ENABLED='YES'
WHERE NAME LIKE 'events_stages_%';
Чтобы видеть ход продолжающегося запроса
ALTER TABLE,
выберите из таблицы
events_stages_current.
23.9.5.1.
Таблица events_stages_current
events_stages_current содержит текущие события этапа, одну строку
на поток, показывая текущий статус нового отслеживаемого
события этапа потока.
Из таблиц, которые содержат строки этапа событий,
events_stages_current
является самой фундаментальной. Другие таблицы, которые содержат
строки этапа событий, логически получены из текущих событий. Например,
events_stages_history
и
events_stages_history_long собирают новые события этапа до
постоянного числа строк.
У
events_stages_current есть эти столбцы:
THREAD_ID, EVENT_ID
Поток, связанный со случаем и числом событий потока,
когда случай запускается. THREAD_ID и EVENT_ID,
взятые вместе, уникально идентифицируют строку. Ни у каких двух строк нет той
же самой пары значений. END_EVENT_ID
Этот столбец установлен в NULL, когда случай запускается, и
обновлен к числу событий потока, когда случай заканчивается. EVENT_NAME
Название инструмента, который произвел случай. Это значение
NAME из
setup_instruments. Инструментальные имена могут иметь много частей
и сформировать иерархию, как обсуждено в
разделе 23.4.
SOURCE
Название исходного файла, содержащего инструментованный код, который
произвел случай и номер строки в файле, в которой происходит
инструментовка. Это позволяет Вам проверить источник, чтобы определить точно,
какой код вовлечен. TIMER_START, TIMER_END,
TIMER_WAIT
Информация о синхронизации для случая. Модуль для этих значений
пикосекунды. TIMER_START и TIMER_END
указывают, когда синхронизация событий запустилась и закончилась.
TIMER_WAIT продолжительность событий.
Если случай не закончился, TIMER_END
текущее значение таймера и TIMER_WAIT время, законченное до сих
пор (TIMER_END - TIMER_START).
Если случай произведен из инструмента, который имеет
TIMED = NO, информация синхронизации не собрана,
TIMER_START, TIMER_END и
TIMER_WAIT все NULL. WORK_COMPLETED, WORK_ESTIMATED
Эти столбцы предоставляют информацию о продвижении этапа для
инструментов, которые были осуществлены, чтобы произвести такую информацию.
WORK_COMPLETED указывает, сколько единиц работы было завершено
для этапа, а WORK_ESTIMATED
указывает, сколько единиц работы ожидается для этапа. NESTING_EVENT_ID
Значение EVENT_ID случая, в пределах которого вложен этот
случай. Событие вложения для случая этапа обычно событие запроса. NESTING_EVENT_TYPE
Тип вложения событий. Значение TRANSACTION,
STATEMENT, STAGE или
WAIT.
У
events_stages_current есть эти индексы:
TRUNCATE TABLE позволен
на
events_stages_current. Это удаляет строки.
23.9.5.2.
Таблица events_stages_history Table
events_stages_history содержит N новых
событий этапа на поток. Значение N определено
при запуске сервера. Чтобы установить табличный размер явно, установите
при запуске сервера переменную
performance_schema_events_stages_history_size. События этапа
не добавлены к таблице, пока они не закончены. Когда новые события добавлены,
от более старых событий отказываются, если таблица полна.
У
events_stages_history есть та же самая структура, как у
events_stages_current
, включая индексы. См.
раздел 23.9.5.1.
TRUNCATE TABLE позволен
на
events_stages_history. Это удаляет строки.
23.9.5.3. Таблица
events_stages_history_long
events_stages_history_long содержит N новых
событий этапа. N определено при запуске сервера. Чтобы
установить табличный размер явно, установите при запуске сервера переменную
performance_schema_events_stages_history_long_size.
События этапа не добавлены к таблице, пока они не закончились. Когда
новые события добавлены, от более старых событий отказываются, если таблица
полна. Когда поток заканчивается, его строки удалены из таблицы.
У
events_stages_history_long есть та же самая структура, как у
events_stages_current
, но нет индексов. См.
раздел 23.9.5.1.
TRUNCATE TABLE позволен
на
events_stages_history_long. Это удаляет строки.
23.9.6.
Таблицы событий запросов Performance Schema
Эти таблицы хранят события запросов:
Конфигурация событий запросов
Чтобы включить сбор событий запросов, включите
соответствующие инструменты и потребителей.
Таблица
setup_instruments содержит инструменты с именами, которые
начинаются с statement. Эти инструменты включены по умолчанию:
mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'statement/%';
+--------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+--------------------------------+---------+-------+
| statement/sql/select | YES | YES |
| statement/sql/create_table | YES | YES |
| statement/sql/create_index | YES | YES |
...
| statement/sp/stmt | YES | YES |
| statement/sp/set | YES | YES |
| statement/sp/set_trigger_field | YES | YES |
| statement/scheduler/event | YES | YES |
| statement/com/Sleep | YES | YES |
| statement/com/Quit | YES | YES |
| statement/com/Init DB | YES | YES |
...
| statement/abstract/Query | YES | YES |
| statement/abstract/new_packet | YES | YES |
| statement/abstract/relay_log | YES | YES |
+--------------------------------+---------+-------+
Чтобы изменить набор событий запросов, измените столбцы
ENABLED и TIMING
соответствующих инструментов. Например:
mysql> UPDATE setup_instruments SET ENABLED = 'NO'
WHERE NAME LIKE 'statement/com/%';
setup_consumers
содержит потребительские значения с именами, соответствующими текущим и
недавним именам событий запросов и потребителю обзора запросов.
Эти потребители могут использоваться, чтобы фильтровать набор событий.
events_statements_current,
events_statements_history и statements_digest
включены по умолчанию:
mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%statements%';
+--------------------------------+---------+
| NAME | ENABLED |
+--------------------------------+---------+
| events_statements_current | YES |
| events_statements_history | YES |
| events_statements_history_long | NO |
| statements_digest | YES |
+--------------------------------+---------+
Чтобы включить всех потребителей, сделайте это:
mysql> UPDATE setup_consumers SET ENABLED = 'YES'
WHERE NAME LIKE '%statements%';
setup_timers
содержит строку со значением NAME statement,
которая указывает на модуль для синхронизации запросы событий.
Модуль по умолчанию NANOSECOND.
mysql> SELECT * FROM setup_timers WHERE NAME = 'statement';
+-----------+------------+
| NAME | TIMER_NAME |
+-----------+------------+
| statement | NANOSECOND |
+-----------+------------+
Чтобы изменить модуль синхронизации,
измените значение TIMER_NAME:
mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'
WHERE NAME = 'statement';
Контроль запросов
Контроль запросов начинается с момента, когда сервер видит, что на
потоке требуется активность, до момента, когда вся деятельность прекратилась.
Как правило, это означает по времени от момента, когда сервер получает первый
пакет от клиента, до времени, когда сервер закончил посылать ответ.
Запросы в пределах сохраненных программ проверены как другие запросы.
Когда Performance Schema инструментует запрос (команду сервера или запрос
SQL), это использует инструментальные имена, которые проистекают из более
общего (или абстрактного) к более определенному, пока это не
достигает заключительного инструментального имени.
Заключительные инструментальные имена соответствуют командам
сервера и запросам SQL:
Команды сервера соответствуют кодам
COM_xxx, определенным в заголовочном файле
mysql_com.h и обработанным в sql/sql_parse.cc.
Примеры: COM_PING и COM_QUIT.
У инструментов для команд есть имена, которые начинаются на
statement/com, к примеру, statement/com/Ping и
statement/com/Quit. - Запросы SQL выражены как текст, такой как
DELETE FROM t1 или SELECT * FROM t2.
У инструментов для запросов SQL есть имена, которые начинаются с
statement/sql, например, statement/sql/delete и
statement/sql/select.
Некоторые заключительные инструментальные имена являются определенными
для обработки ошибок:
statement/com/Error считает
сообщения, полученные сервером, которые являются вне группы. Это может
использоваться, чтобы обнаружить команды, посланные клиентами, которых не
понимает сервер. Это может быть полезно в таких целях, как идентификация
клиентов, которые являются неправильно настроенными или используют версии
MySQL, более свежие, чем сервер, или клиенты, которые пытаются
напасть на сервер.
statement/sql/error считает запросы SQL, которые сервер не
в состоянии разобрать. Это может использоваться, чтобы обнаружить уродливые
запросы, посланные клиентами. Запрос, который сервер не в состоянии
разобрать, отличается от запроса, который разбирает, но терпит неудачу из-за
ошибки во время выполнения. Например, SELECT * FROM
неправилен, и используется инструмент statement/sql/error.
В отличие от этого, SELECT * разобран, но терпит неудачу с
ошибкой No tables used. В этом случае используется
statement/sql/select и случай запроса содержит информацию, чтобы
указать на природу ошибки.
Запрос может быть получен из любого из этих источников:
Детали для запроса первоначально неизвестны и Performance Schema
раблтает от абстрактных до определенных инструментальных имен в
последовательности, которая зависит от источника запроса.
Для запроса, полученного от клиента:
Когда сервер обнаруживает новый пакет на уровне сокета,
новое запрос запущен с абстрактного инструментального названия
statement/abstract/new_packet. - Когда сервер читает число пакетов, он знает больше о типе полученного
запроса, и Performance Schema совершенствует инструментальное имя. Например,
если запрос пакет
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,
потому что никакой запрос никогда не классифицируется с абстрактным
инструментом как заключительным именем запроса.
23.9.6.1.
Таблица The events_statements_current
events_statements_current содержит текущие события запроса, одну
строку на поток, показывая текущий статус новых отслеживаемых за развитием
события запросов потока.
Из таблиц, которые содержат строки запросов событий,
events_statements_current является самой фундаментальной. Другие
таблицы, которые содержат строки запросы событий, логически получены из
текущих событий. Например,
events_statements_history и
events_statements_history_long собирают
новые события запроса до постоянного числа строк.
У
events_statements_current есть эти столбцы:
THREAD_ID, EVENT_ID.
Поток, связанный со случаем и текущим числом событий потока,
когда случай запускается. THREAD_ID и EVENT_ID
вместе уникально идентифицируют строку. Ни у каких двух строк нет той же
самой пары значений. END_EVENT_ID
Этот столбец установлен в NULL, когда случай запускается
и обновлен к числу событий потока, когда случай заканчивается. EVENT_NAME
Название инструмента, у которого был собран случай. Это NAME
из таблицы
setup_instruments. Инструментальные имена могут иметь много частей
и сформировать иерархию, как обсуждено в
разделе 23.4.
Для запросов SQL EVENT_NAME первоначально
statement/com/Query пока запрос не разобран, затем изменяется на
более соответствующее значение, как описано в
разделе 23.9.6.
SOURCE
Название исходного файла, содержащего инструментованный код, который
произвел случай и номер строки в файле, в котором происходит инструментовка.
Это позволяет Вам проверить источник, чтобы определить точно,
какой код вовлечен. TIMER_START, TIMER_END,
TIMER_WAIT
Информация о синхронизации для случая. Модуль для этих значений
пикосекунды TIMER_START и TIMER_END
указывают, когда синхронизация событий запустилась и закончилась.
TIMER_WAIT продолжительность событий.
Если случай не закончился, TIMER_END
текущее значение таймера и TIMER_WAIT
время, законченное до сих пор
(TIMER_END - TIMER_START).
Если случай произведен из инструмента, который имеет
TIMED = NO, информация синхронизации не собрана, а
TIMER_START, TIMER_END и
TIMER_WAIT NULL. LOCK_TIME
Время, потраченное на ожидание табличных блокировок. Это значение
вычислено в микросекундах, но нормализовано к пикосекундам для более легкого
сравнения с другими таймерами Performance Schema. SQL_TEXT
Текст запроса SQL. Для команды, не связанной с запросом
SQL, значение NULL.
Максимальное количество байтов, чтобы вывести на экран может быть
изменено, изменяя при запуске сервера переменную
performance_schema_max_sql_text_length. DIGEST
Обзор запроса MD5 как строка из 32 шестнадцатеричных символов или
NULL, если потребитель
statement_digest no. DIGEST_TEXT
Нормализованный текст обзора запроса или NULL, если
потребитель statement_digest no.
Перменная
performance_schema_max_digest_length
определяет максимальное количество байтов, доступных для вычислительных
обзоров запроса. Однако, длина отображения обзоров запроса может быть более
длительной, чем доступный размер буфера из-за кодирования компонентов
запроса, таких как ключевые слова и буквальные значения в буфере обзора.
Следовательно, значения, выбранные из столбца DIGEST_TEXT
таблиц событий запроса, может казаться, превышает
performance_schema_max_digest_length. CURRENT_SCHEMA
База данных значения по умолчанию для запроса,
NULL, если нет. OBJECT_SCHEMA, OBJECT_NAME,
OBJECT_TYPE
Для вложенных запросов (сохраненные программы), эти столбцы содержат
информацию о родительском запросе. Иначе NULL. OBJECT_INSTANCE_BEGIN
Этот столбец идентифицирует запрос. Значение адрес объекта в памяти. MYSQL_ERRNO
Код ошибки из области диагностики. RETURNED_SQLSTATE
Значение SQLSTATE из области диагностики. MESSAGE_TEXT
Сообщение об ошибке запроса из области диагностики. ERRORS
Произошла ли ошибка для запроса. Значение 0, если значение SQLSTATE
начинается с 00 (выполнен) или 01 (предупреждение).
Значение 1, если SQLSTATE иное. WARNINGS
Число предупреждений из области диагностики. ROWS_AFFECTED
Число строк, затронутых запросом. Для описания значения
"затронутых" см.
раздел 25.8.7.1. ROWS_SENT
Число строк, возвращенных запросом. ROWS_EXAMINED
Число строк, прочитанных из механизмов хранения во
время выполнения запроса. CREATED_TMP_DISK_TABLES
Как переменная состояния
Created_tmp_disk_tables, но для запроса. CREATED_TMP_TABLES
Как переменная состояния
Created_tmp_tables, но для запроса. SELECT_FULL_JOIN
Как переменная состояния
Select_full_join, но для запроса. SELECT_FULL_RANGE_JOIN
Как переменная состояния
Select_full_range_join, но для запроса. SELECT_RANGE
Как переменная состояния
Select_range,
но для запроса. SELECT_RANGE_CHECK
Как переменная состояния
Select_range_check, но для запроса. SELECT_SCAN
Как переменная состояния
Select_scan,
но для запроса. SORT_MERGE_PASSES
Как переменная состояния
Sort_merge_passes
, но для запроса. SORT_RANGE
Как переменная состояния
a href="server.htm#statvar_Sort_range">Sort_range,
но для запроса. SORT_ROWS
Как переменная состояния
Sort_rows,
но для запроса. SORT_SCAN
Как переменная состояния
Sort_scan,
но для запроса. NO_INDEX_USED
1, если запрос выполнил сканирование таблицы, не
используя индексирование, 0 иначе. NO_GOOD_INDEX_USED
1, если сервер не нашел индекс, чтобы использовать для запроса, 0 иначе.
Для дополнительной информации см. описание столбца Extra из
вывода EXPLAIN для значения
Range checked for each record
разделе 9.8.2. NESTING_EVENT_ID, NESTING_EVENT_TYPE,
NESTING_EVENT_LEVEL
Эти три столбца используются с другими столбцами, чтобы предоставить
информацию следующим образом для запросов верхнего уровня (невложенных) и
вложенные запросы (выполненных в пределах сохраненной программы).
Для высокоуровневых запросов:
OBJECT_TYPE = NULL
OBJECT_SCHEMA = NULL
OBJECT_NAME = NULL
NESTING_EVENT_ID = NULL
NESTING_EVENT_TYPE = NULL
NESTING_LEVEL = 0
Для вложенных запросов:
OBJECT_TYPE = родительский тип объекта запроса
OBJECT_SCHEMA = родительская схема объекта
OBJECT_NAME = родительское название объекта
NESTING_EVENT_ID = EVENT_ID родительского запроса
NESTING_EVENT_TYPE = 'STATEMENT'
NESTING_LEVEL = NESTING_LEVEL родительского запроса+1
У
events_statements_current есть эти индексы:
TRUNCATE TABLE позволен
на
events_statements_current. Это удаляет строки.
23.9.6.2.
Таблица events_statements_history
events_statements_history содержит N новых
событий запроса на поток. Значение N задано
при запуске сервера. Чтобы установить табличный размер явно, установите
при запуске сервера переменную
performance_schema_events_statements_history_size.
Событие запроса не добавлено к таблице, пока оно не закончено. Когда
новые события добавлены, от более старых событий отказываются,
если таблица полна.
events_statements_history имеет ту же структуру, что и
events_statements_current. См.
раздел 23.9.6.1.
TRUNCATE TABLE позволен
на
events_statements_history. Это удаляет строки.
23.9.6.3.
Таблица events_statements_history_long
events_statements_history_long содержит N
новых событий запроса. Значение N задано при запуске
сервера. Чтобы установить табличный размер явно, установите при
запуске сервера переменную
performance_schema_events_statements_history_long_size.
События не добавлены к таблице, пока они не закончились. Когда
новые события добавлены, от более старых событий отказываются, если таблица
полна. Когда поток заканчивается, его строки удалены из таблицы.
events_statements_history_long имеет ту же структуру, что и
events_statements_current, но без индексов. См.
раздел 23.9.6.1.
TRUNCATE TABLE позволен
на
events_statements_history_long. Это удаляет строки.
23.9.6.4.
Таблица prepared_statements_instances
Performance Schema обеспечивает инструментовку для готовых запросов, для
которых есть два протокола:
Протокол двоичной синхронной передачи данных. К этому получают
доступ через MySQL C API, и он отображается на основные команды сервера как
показано в следующей таблице.
Текстовый протокол. К этому получают доступ, используя запросы SQL и
отображая на основные команды сервера, как показано в следующей таблице.
Performance Schema подготовила покрытие инструментовки обоих протоколов.
Следующее обсуждение отсылает к командам сервера, а не функциям C API
или запросам SQL.
Информация о готовых запросах доступна в таблице
prepared_statements_instances. Эта таблица включает просмотр
готовых запросов, используемых в сервере, и обеспечивает соединенную
статистику о них. Чтобы управлять размером этой таблицы, установите
при запуске сервера системную переменную
performance_schema_max_prepared_statements_instances.
Сбор готовой информации о запросе зависит от инструментов запроса,
показанных в следующей таблице. Эти инструменты включены по умолчанию. Чтобы
изменить их, обновите
setup_instruments.
| Инструмент | Команда сервера
|
|---|
statement/com/Prepare |
COM_STMT_PREPARE |
statement/com/Execute |
COM_STMT_EXECUTE |
statement/sql/prepare_sql |
SQLCOM_PREPARE |
statement/sql/execute_sql |
SQLCOM_EXECUTE |
Performance Schema управляет содержанием
prepared_statements_instances следующим образом:
Подготовка запроса.
Команда COM_STMT_PREPARE или SQLCOM_PREPARE
создает готовый запрос в сервере. Если запрос успешно инструментован, новая
строка добавлена к
prepared_statements_instances.
Если запрос не может быть инструментован, увеличена переменная
Performance_schema_prepared_statements_lost. - Выполнение готового запроса.
Выполнение команды COM_STMT_EXECUTE или
SQLCOM_PREPARE для инструментованного готового случая запроса
обновляет соответствующую строку таблицы
prepared_statements_instances.
- Освобождение готового запроса.
Выполнение команды COM_STMT_CLOSE или
SQLCOM_DEALLOCATE_PREPARE для инструментованного готового случая
запроса удаляет соответствующую строку таблицы
prepared_statements_instances. Чтобы избежать утечек ресурса,
удаление происходит, даже если инструменты готового запроса,
описанные ранее, отключены.
У
prepared_statements_instances есть эти столбцы:
OBJECT_INSTANCE_BEGIN
Адрес в памяти инструментованного готового запроса. STATEMENT_ID
Внутренний ID, назначенный сервером. STATEMENT_NAME
Для протокола двоичной синхронной передачи данных этот столбец
NULL. Для текстового протокола этот столбец внешнее имя,
назначенное пользователем. Например, для следующего запроса SQL, название
готового запроса stmt:
PREPARE stmt FROM 'SELECT 1';
SQL_TEXT
Готовый текст запроса с маркерами заполнителями ?. OWNER_THREAD_ID, OWNER_EVENT_ID
Эти столбцы указывают на событие, которое создало готовый запрос. OWNER_OBJECT_TYPE, OWNER_OBJECT_SCHEMA,
OWNER_OBJECT_NAME
Для готового запроса, создаваемого сеансом клиента, эти столбцы
NULL. Для готового запроса, создаваемого сохраненной программой,
эти столбцы указывают на сохраненную программу. Типичная пользовательская
ошибка в том, что пользователь забывает освобождать подготовленные запросы.
Эти столбцы могут использоваться, чтобы найти сохраненные программы, которые
пропускают готовые запросы:
SELECT OWNER_OBJECT_TYPE, OWNER_OBJECT_SCHEMA, OWNER_OBJECT_NAME,
STATEMENT_NAME, SQL_TEXT
FROM performance_schema.prepared_statements_instances
WHERE OWNER_OBJECT_TYPE IS NOT NULL;
TIMER_PREPARE
Время на выполнение подготовки запроса. COUNT_REPREPARE
Сколько раз запрос был повторно подготовлено внутренне (см.
раздел 9.10.4).
Статистические данные синхронизации для переподготовки недоступны, потому
что это посчитано как часть выполнения запроса, не как отдельная работа. COUNT_EXECUTE, SUM_TIMER_EXECUTE,
MIN_TIMER_EXECUTE, AVG_TIMER_EXECUTE,
MAX_TIMER_EXECUTE
Соединенная статистика для выполнения готового запроса. SUM_xxx
Остающееся столбцы SUM_xxx
то же самое, что касается сводных таблиц запросов (см.
раздел 23.9.15.3).
У
prepared_statements_instances есть эти индексы:
TRUNCATE TABLE
сбрасывает столбцы статистики
prepared_statements_instances.
23.9.7.
Операционные таблицы Performance Schema
Эти таблицы хранят операционные события:
Операционная конфигурация событий
Чтобы включить сбор операционных событий, включите
соответствующие инструменты и потребителей.
setup_instruments
содержит инструмент transaction.
Этот инструмент отключен по умолчанию:
mysql> SELECT * FROM setup_instruments WHERE NAME = 'transaction';
+-------------+---------+-------+
| NAME | ENABLED | TIMED |
+-------------+---------+-------+
| transaction | NO | NO |
+-------------+---------+-------+
Чтобы включить сбор операционных событий,
включая информацию о синхронизации:
mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME = 'transaction';
setup_consumers
содержит потребительские значения с именами, соответствующими текущим и
недавним операционным именам таблиц событий. Эти потребители могут
использоваться, чтобы фильтровать набор операционных событий:
mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%transactions%';
+----------------------------------+---------+
| NAME | ENABLED |
+----------------------------------+---------+
| events_transactions_current | NO |
| events_transactions_history | NO |
| events_transactions_history_long | NO |
+----------------------------------+---------+
Чтобы включить всех операционных потребителей:
mysql> UPDATE setup_consumers SET ENABLED = 'YES'
WHERE NAME LIKE '%transactions%';
Чтобы включить сбор операционных событий только для определенных
операционных таблиц событий, включите
соответствующих операционных потребителей.
setup_timers
содержит строку с NAME transaction, которая
указывает на модуль для операционной синхронизации событий.
Модуль по умолчанию NANOSECOND.
mysql> SELECT * FROM setup_timers WHERE NAME = 'transaction';
+-------------+------------+
| NAME | TIMER_NAME |
+-------------+------------+
| transaction | NANOSECOND |
+-------------+------------+
Чтобы изменить модуль синхронизации, измените TIMER_NAME:
mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND'
WHERE NAME = 'transaction';
Операционные границы
В MySQL Server транзакции запускаются явно с этих запросов:
START TRANSACTION | BEGIN | XA START | XA BEGIN
Транзакции также запускаются неявно. Например, когда включена переменная
autocommit,
запуск каждого запроса запускает новую транзакцию.
Если autocommit
выключена, первый запрос после переданной транзакции отмечает запуск новой
транзакции. Последующие запросы это часть транзакции, пока это не передано.
Транзакции явно заканчиваются этими запросами:
COMMIT | ROLLBACK | XA COMMIT | XA ROLLBACK
Транзакции также заканчиваются неявно, выполнением запросов DDL, запросами
блокировки и запросами администрирования сервера.
В следующем обсуждении ссылки на
START TRANSACTION также применимы к
BEGIN,
XA START и
XA BEGIN. Точно так же
ссылки на COMMIT и
ROLLBACK относятся к
XA COMMIT и
XA ROLLBACK.
Performance Schema определяет операционные границы аналогично серверу.
Запуск и конец операционного случая близко соответствуют соответствующим
изменениям состояния в сервере:
Есть тонкие значения к этому подходу:
Операционные события в 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, которые совместимы с тем, как сервер пишет
транзакции в двоичный журнал.
Операционная инструментовка
Три признака определяют транзакции:
Чтобы уменьшить сложность операционной инструментовки и гарантировать, что
собранные операционные данные обеспечивают полные, значащие результаты, все
транзакции инструментованы независимо от режима доступа, уровня изоляции
или режима autocommit.
Чтобы выборочно исследовать операционную историю, используйте столбцы
признака в операционных таблицах событий: ACCESS_MODE,
ISOLATION_LEVEL и AUTOCOMMIT.
Стоимость операционной инструментовки может быть уменьшена различными
путями, такими как включение или отключение операционной инструментовки,
согласно пользователю, учетной записи, узлу или потоку (соединению клиента).
Транзакции и вложенные события
Родитель операционного случая это случай, который начал транзакцию.
Для явно запущенной транзакции это включает
START TRANSACTION и
COMMIT AND CHAIN. Для неявно
запущенной транзакции это первый запрос, который использует транзакционный
механизм после того, как предыдущая транзакция заканчивается.
Вообще, транзакция высокоуровневый родитель ко всем событиям, начатым во
время транзакции, включая запросы, которые явно заканчивают транзакцию, такие
как COMMIT и
ROLLBACK. Исключения: запросы,
которые неявно заканчивают транзакцию, такие как запросы DDL, когда текущая
транзакция должна быть закрыта прежде, чем новый запрос выполнен.
Транзакции и сохраненные программы
Транзакции и сохраненные события программы связаны следующим образом:
Хранимые процедуры.
Хранимые процедуры работают независимо от транзакций. Хранимая процедура
может быть запущена в пределах транзакции, и транзакция может быть запущена
или закончена изнутри хранимой процедуры. Если вызвана изнутри транзакции,
хранимая процедура может выполнить запросы, которые вызывают передачу
родительской транзакции и затем запускают новую транзакцию.
Если хранимая процедура запущена в пределах транзакции, та транзакция
родитель случая хранимой процедуры.
Если транзакция запущена хранимой процедурой, хранимая процедура
родитель операционного случая. - Сохраненные функции.
Сохраненные функции ограничены от порождения явной или неявной передачи
или отмены транзакции. Сохраненные функциональные события могут находиться в
пределах родительского операционного случая.
- Триггеры.
Триггеры активируются как часть запроса, обращающегося
к таблице, с которой он связан, таким образом, родитель случая триггера
всегда запрос, который активирует его.
Триггеры не могут сделать запросы, которые вызывают явную или неявную
передают или отмену транзакции.
- Запланированные события.
Выполнение запросов в теле запланированного события
имеет место в новом соединении. Вложение запланированного события
в пределы родительской транзакции неприменимо.
Транзакции и Savepoints
Запросы Savepoint зарегистрированы как отдельные события.
Операционные события включают отдельные счетчики для
SAVEPOINT,
ROLLBACK TO SAVEPOINT и
RELEASE SAVEPOINT, которые
произошли во время транзакции.
Транзакции и ошибки
Ошибки и предупреждения, которые происходят в пределах транзакции,
зарегистрированы в событиях запросов, но не в соответствующем операционном
событии. Это включает определенные для транзакции ошибки и предупреждения,
такие как отмена транзакции на нетранзакционный таблице или
ошибка последовательности GTID.
23.9.7.1.
Таблица events_transactions_current
events_transactions_current содержит текущие операционные события,
одну строку на поток, показывая текущий статус нового
отслеживающего потока. Например:
mysql> SELECT * FROM events_transactions_current LIMIT 1\G
*************************** 1. row ***************************
THREAD_ID: 26
EVENT_ID: 7
END_EVENT_ID: NULL
EVENT_NAME: transaction
STATE: ACTIVE
TRX_ID: NULL
GTID: 3E11FA47-71CA-11E1-9E33-C80AA9429562:56
XID: NULL
XA_STATE: NULL
SOURCE: transaction.cc:150
TIMER_START: 420833537900000
TIMER_END: NULL
TIMER_WAIT: NULL
ACCESS_MODE: READ WRITE
ISOLATION_LEVEL: REPEATABLE READ
AUTOCOMMIT: NO
NUMBER_OF_SAVEPOINTS: 0
NUMBER_OF_ROLLBACK_TO_SAVEPOINT: 0
NUMBER_OF_RELEASE_SAVEPOINT: 0
OBJECT_INSTANCE_BEGIN: NULL
NESTING_EVENT_ID: 6
NESTING_EVENT_TYPE: STATEMENT
Из таблиц, которые содержат операционные строки событий,
events_transactions_current является самой фундаментальной. Другие
таблицы, которые содержат операционные строки событий, логически получены из
текущих событий. Например,
events_transactions_history и
events_transactions_history_long
собирают новые операционные события до постоянного числа строк.
У
events_transactions_current есть эти столбцы:
THREAD_ID, EVENT_ID
Поток, связанный со случаем и текущим числом событий потока, когда случай
запускается. THREAD_ID и EVENT_ID вместе
уникально идентифицируют строку. Ни у каких двух строк нет той же
самой пары значений. END_EVENT_ID
Этот столбец установлен в NULL, когда случай запускается и
обновлен к текущему числу событий потока, когда случай заканчивается. EVENT_NAME
Название инструмента, у которого был собран случай. Это NAME
из setup_instruments
. Инструментальные имена могут иметь много частей и сформировать
иерархию, как обсуждено в
разделе 23.4.
STATE
Текущее операционное состояние. Значение ACTIVE (после
START TRANSACTION или
BEGIN), COMMITTED
(после COMMIT) или ROLLED
BACK (после ROLLBACK). TRX_ID
Не использован. GTID
Столбец GTID содержит значение
gtid_next,
которое может быть одним из ANONYMOUS, AUTOMATIC
или GTID с использованием формата UUID:NUMBER.
Для транзакций с использованием
gtid_next=AUTOMATIC (это все нормальные транзакции клиента),
столбец GTID меняется, когда транзакция завершается и фактический GTID
назначен. Если gtid_mode
ON или ON_PERMISSIVE, столбец GTID
изменяется на GTID транзакции. Если gtid_mode OFF
или OFF_PERMISSIVE, столбец GTID
изменяется на ANONYMOUS. XID_FORMAT_ID, XID_GTRID,
XID_BQUAL
Компоненты операционного идентификатора XA. Их формат описан в
разделе 14.3.7.1. XA_STATE
Состояние транзакции XA. Значение ACTIVE (после
XA START), IDLE
(после XA END),
PREPARED (после XA
PREPARE), ROLLED BACK (после
XA ROLLBACK) или
COMMITTED (после XA
COMMIT). SOURCE
Название исходного файла, содержащего инструментованный код, который
произвел случай и номер строки в файле, в котором происходит инструментовка.
Это позволяет Вам проверить источник, чтобы определить точно,
какой код вовлечен. TIMER_START, TIMER_END,
TIMER_WAIT
Информация о синхронизации для случая. Модуль для этих значений
пикосекунды. TIMER_START и TIMER_END
указывают, когда синхронизация событий запустилась и закончилась.
TIMER_WAIT продолжительность.
Если случай не закончился, TIMER_END текущее значение
таймера и TIMER_WAIT время, законченное до сих пор
(TIMER_END - TIMER_START).
Если случай произведен из инструмента, который имеет
TIMED = NO, информация синхронизации не собрана, и
TIMER_START, TIMER_END и
TIMER_WAIT NULL. ACCESS_MODE
Операционный режим доступа. Значение READ ONLY
или READ WRITE. ISOLATION_LEVEL
Операционный уровень изоляции. Значение
REPEATABLE READ
, READ COMMITTED
, READ
UNCOMMITTED или
SERIALIZABLE. AUTOCOMMIT
Был ли режим autcommit включен, когда транзакция запускалась. NUMBER_OF_SAVEPOINTS,
NUMBER_OF_ROLLBACK_TO_SAVEPOINT,
NUMBER_OF_RELEASE_SAVEPOINT
Число запросов SAVEPOINT,
ROLLBACK TO SAVEPOINT и
RELEASE SAVEPOINT
во время транзакции. OBJECT_INSTANCE_BEGIN
Не использован. NESTING_EVENT_ID
EVENT_ID случая, в пределах которого вложен этот случай.
NESTING_EVENT_TYPE
Тип вложения событий. Значение
TRANSACTION, STATEMENT, STAGE или
WAIT. TRANSACTION не будет появляться, потому что
транзакции не могут быть вложены.
У
events_transactions_current есть эти индексы:
TRUNCATE TABLE позволен
на
events_transactions_current. Это удаляет строки.
23.9.7.2.
Таблица events_transactions_history
Таблица
events_transactions_history хранит N
последних операционных событий на поток. Значение N
задано при запуске сервера. Чтобы установить табличный размер явно,
установите системную переменную
performance_schema_events_transactions_history_size
при запуске сервера. Операционные события не добавлены к таблице, пока они не
закончены. Когда новые события добавлены, от более старых событий
отказываются, если таблица полна.
Таблица
events_transactions_history имеет ту же самую структуру, как
events_transactions_current, включая индексацию. См.
раздел 23.9.7.1.
TRUNCATE TABLE позволен
на
events_transactions_history. Это удаляет строки.
23.9.7.3.
Таблица events_transactions_history_long
Таблица
events_transactions_history_long хранит N
новых операционных событий. Значение N
задано при запуске сервера. Чтобы установить табличный размер явно,
установите при запуске сервера системную переменную
performance_schema_events_transactions_history_long_size.
Операционные события не добавлены к таблице, пока они не закончены. Когда
новые события добавлены, от более старых событий отказываются, если таблица
полна. Когда поток заканчивается, его строки удалены из таблицы.
У
events_transactions_history_long та же самая структура, как у
events_transactions_current, за исключением того, что это не имеет
индексов. См. раздел
23.9.7.1.
TRUNCATE TABLE позволен
на
events_transactions_history_long. Это удаляет строки.
23.9.8.
Таблицы соединения Performance Schema
Когда клиент соединяется с сервером MySQL, он делает это под именем
пользователя и от конкретного узла. Performance Schema
обеспечивает статистику об этих соединениях, отслеживая их для учетной записи
(комбинация пользователя и узла), а также отдельно для имени пользователя и
имени хоста, используя эти таблицы:
Значение account в таблицах соединения подобно его значению в
таблицах привилегий MySQL базы данных mysql,
в том смысле, что термин относится к комбинации значений узла и пользователя.
Они отличаются в том, что для таблиц привилегий часть узла учетной записи
может быть образцом, тогда как для Performance Schema значение узла всегда
определенное имя хоста.
Каждая таблица соединения имеет столбцы CURRENT_CONNECTIONS и
TOTAL_CONNECTIONS, чтобы отследить текущее и общее количество
соединений за преиод слежения на котором базируются
статистические данные. Таблицы отличаются по тому, что они используют для
значения отслеживания. Таблица
accounts имеет столбцы
USER и HOST, чтобы отследить соединения на
комбинацию пользователя и узла. users
и hosts имеют
столбцы USER и HOST, соответственно, чтобы
отследить соединения за имя пользователя и имя хоста.
Performance Schema также считает внутренние потоки и потоки для
пользовательских сеансов, которые были не в состоянии подтвердить
подлинность, используя строки со столбцами
USER и HOST NULL.
Предположите, что клиенты user1 и user2
соединились с машин hosta и hostb. Performance
Schema отслеживает соединения следующим образом:
Таблица 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 позволен
на таблицах соединения. Это имеет эффекты:
Performance Schema поддерживает сводные таблицы, которые ведут совокупную
статистику соединений для различных типов случаев по учетной записи, узлу или
пользователю. Эти таблицы имеют в имени _summary_by_account,
_summary_by_host или _summary_by_user.
Чтобы идентифицировать их, используйте этот запрос:
mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'performance_schema' AND
TABLE_NAME REGEXP '_summary_by_(account|host|user)'
ORDER BY TABLE_NAME;
+------------------------------------------------------+
| TABLE_NAME |
+------------------------------------------------------+
| events_errors_summary_by_account_by_error|
| events_errors_summary_by_host_by_error |
| events_errors_summary_by_user_by_error |
| events_stages_summary_by_account_by_event_name |
| events_stages_summary_by_host_by_event_name|
| events_stages_summary_by_user_by_event_name|
| events_statements_summary_by_account_by_event_name |
| events_statements_summary_by_host_by_event_name|
| events_statements_summary_by_user_by_event_name|
| events_transactions_summary_by_account_by_event_name |
| events_transactions_summary_by_host_by_event_name|
| events_transactions_summary_by_user_by_event_name|
| events_waits_summary_by_account_by_event_name |
| events_waits_summary_by_host_by_event_name |
| events_waits_summary_by_user_by_event_name |
| memory_summary_by_account_by_event_name |
| memory_summary_by_host_by_event_name |
| memory_summary_by_user_by_event_name |
+------------------------------------------------------+
Для деталей об отдельных сводных таблицах соединения, консультируйтесь с
разделом, который описывает таблицы для полученного в итоге типа событий:
TRUNCATE TABLE позволен
на сводных таблицах соединения. Это удаляет строки для учетных записей, узлов
или пользователей без соединений и сбрасывает сводные столбцы к нолю для
остающихся строк. Кроме того, каждая сводная таблица, которая собирает данные
соединения по учетной записи, узлу, пользователю или потоку, неявно усечена
усечением таблицы соединения, от которой зависит. Следующая таблица описывает
отношения между табличным усечением соединения и неявно усеченными таблицами.
Таблица 23.2.
Неявные эффекты табличного усечения соединения
| Усеченная таблица соединения |
Неявно усеченные сводные таблицы |
|---|
accounts |
Таблицы с именами, содержащими _summary_by_account,
_summary_by_thread |
hosts |
Таблицы с именами, содержащими _summary_by_account,
_summary_by_host, _summary_by_thread |
users |
Таблицы с именами, содержащими _summary_by_account,
_summary_by_user, _summary_by_thread |
Усечение _summary_global также неявно усекает свое
соответствующее соединение и сводные таблицы потока. Например, усечение
events_waits_summary_global_by_event_name
неявно усекает сводные таблицы событий ожидания, которые соединены с учетной
записью, узлом, пользователем или потоком.
23.9.8.1. Таблица accounts
Таблица accounts
содержит строку для каждой учетной записи, которая соединилась с сервером
MySQL. Для каждой учетной записи таблица считает текущее и общее количество
соединений. Табличный размер задан при запуске сервера.
Чтобы установить табличный размер явно, установите системную переменную
performance_schema_accounts_size при запуске сервера.
Чтобы отключить статистику учетной записи, установите эту переменную в 0.
Таблица accounts
имеет следующие столбцы. Для описания того, как Performance Schema
поддерживает строки в этой таблице, включая эффект
TRUNCATE TABLE, см.
раздел 23.9.8.
USER
Имя пользователя клиента для соединения. Это NULL
для внутреннего потока или для пользовательского сеанса, который был не в
состоянии подтвердить подлинность. HOST
Узел, с которого соединялся клиент. Это NULL
для внутреннего потока или для пользовательского сеанса, который был не в
состоянии подтвердить подлинность. CURRENT_CONNECTIONS
Текущее число соединений для учетной записи. TOTAL_CONNECTIONS
Общее количество соединений для учетной записи.
У accounts
есть эти индексы:
23.9.8.2. Таблица hosts
Таблица hosts
содержит строку для каждого узла, с которого клиенты соединились с сервером
MySQL. Для каждого имени хоста таблица считает текущее и общее количество
соединений. Табличный размер задан при запуске сервера. Чтобы установить
табличный размер явно, установите системную переменную
performance_schema_hosts_size при запуске сервера.
Чтобы отключить статистику учетной записи, установите эту переменную в 0.
Таблица hosts
имеет следующие столбцы. Для описания того, как Performance Schema
поддерживает строки в этой таблице, включая эффект
TRUNCATE TABLE, см.
раздел 23.9.8.
HOST
Узел, от которого соединялся клиент. Это NULL
для внутреннего потока или для пользовательского сеанса, который был не в
состоянии подтвердить подлинность. CURRENT_CONNECTIONS
Текущее число соединений для учетной записи. TOTAL_CONNECTIONS
Общее количество соединений для учетной записи.
У hosts
есть эти индексы:
23.9.8.3. Таблица users
Таблица users
содержит строку для каждого пользователя, который соединился с сервером
MySQL. Для каждого имени пользователя таблица считает текущее и общее
количество соединений. Табличный размер задан при запуске сервера. Чтобы
установить табличный размер явно, установите переменную
performance_schema_users_size при запуске сервера. Чтобы отключить
пользовательскую статистику, установите эту переменную в 0.
У таблицы users
есть следующие столбцы. Для описания того, как Performance Schema
поддерживает строки в этой таблице, включая эффект
TRUNCATE TABLE, см.
раздел 23.9.8.
HOST
Узел, от которого соединялся клиент. Это NULL
для внутреннего потока или для пользовательского сеанса, который был не в
состоянии подтвердить подлинность. CURRENT_CONNECTIONS
Текущее число соединений для учетной записи. TOTAL_CONNECTIONS
Общее количество соединений для учетной записи.
У users
есть эти индексы:
23.9.9.
Таблицы атрибутов соединения Performance Schema
Приложения могут предоставить пары ключ/значение как атрибуты соединения
для передачи серверу во время соединения. Для C API определите набор
признака, используя функции
mysql_options() и
mysql_options4().
Другие MySQL Connector могут обеспечить свои собственные методы определения.
Эти таблицы выставляют информацию атрибута:
Названия атрибутов, которые начинаются с подчеркивания
(_), сохранены для внутреннего пользования и не должен быть
созданы приложениями. Это соглашение разрешает новым признакам быть
введенными MySQL, не сталкиваясь с признаками приложения.
Набор признаков соединения, видимых в данном соединении, изменяется в
зависимости от Вашей платформы и MySQL Connector,
которым установили соединение.
Библиотека клиента libmysqlclient (обеспечена в
MySQL и MySQL Connector/C) устанавливает эти признаки:
Прочие MySQL Connector могут определить свои
собственные признаки соединения.
MySQL Connector/J определяет эти признаки:
MySQL Connector/Net определяет эти признаки:
PHP определяет признаки, которые зависят от того, как он был собран:
Много программ клиента MySQL устанавливают признак
program_name со значением, равным имени клиента. Например,
mysqladmin
и mysqldump
устанавливают program_name в
mysqladmin и mysqldump, соответственно.
Некоторые программы клиента MySQL определяют дополнительные признаки:
Есть пределы на количестве данных о признаке соединения,
переданных от клиента к серверу: фиксированный предел наложен клиентом до
времени соединения, фиксированный предел наложен сервером во время соединения
и конфигурируемый предел наложен Performance Schema во время соединения.
Для соединений, начатых, используя C API, библиотека
libmysqlclient налагает предел 64 КБ на совокупный размер данных
о признаке соединения по стороне клиента: вызовы
mysql_options(), которые
превышают этот предел, производят ошибку
CR_INVALID_PARAMETER_NO. Другие MySQL Connector
могут наложить свои собственные клиентские пределы на то, сколько данных о
признаке соединения может быть передано серверу.
На стороне сервера данные о признаке соединения проверяются так:
Сервер налагает предел 64 КБ на совокупный размер данных о
признаке соединения, который примет. Если клиент пытается послать больше
64 КБ данных о признаке, сервер отклоняет соединение. Иначе, сервер полагает,
что признак допустимый и отслеживает размер самого длинного буфера признака
в статусной переменной
Performance_schema_session_connect_attrs_longest_seen. - Для принятых соединений Performance Schema проверяет совокупный размер
признака по значению переменной
performance_schema_session_connect_attrs_size.
Если размер признака превышает это значение, эти действия имеют место:
Performance Schema усекает данные о признаке и увеличивает
переменную
Performance_schema_session_connect_attrs_lost, которая
указывает число соединений, для которых произошло усечение признака. - Performance Schema пишет сообщение в журнал ошибок, если
log_warnings
больше, чем ноль:
Connection attributes of length N were truncated (N bytes lost)
for connection N, user
user_name@host_name
(as user_name), auth: {yes|no}
Информация в предупреждающем сообщении предназначена, чтобы помочь DBA
идентифицировать клиентов, для которых произошло усечение признака.
- Признак
_truncated добавлен к признакам сеанса со значением,
указывающим, сколько байтов было потеряно, если у буфера признака есть
достаточное пространство. Это позволяет Performance Schema выставить
информацию об усечении на соединение в таблицах атрибутов соединения.
Эта информация может быть исследована, не имея необходимости
проверять журнал ошибок.
23.9.9.1.
Таблица session_account_connect_attrs
Приложения могут обеспечить признаки соединения ключа/значения,
которые передадут к серверу во время соединения, используя функции C API
the mysql_options() и
mysql_options4().
session_account_connect_attrs
содержит признаки соединения только для сеансов для Вашей собственной учетной
записи. Чтобы видеть признаки соединения для всех сеансов, загляните в
session_connect_attrs
.
У
session_account_connect_attrs есть эти столбцы:
PROCESSLIST_ID
Идентификатор соединения для сеанса. ATTR_NAME
Название атрибута. ATTR_VALUE
Значение атрибута. ORDINAL_POSITION
Порядок, в котором признак был добавлен к набору признаков соединения.
У
session_account_connect_attrs есть эти индексы:
TRUNCATE TABLE не
позволен для
session_account_connect_attrs.
23.9.9.2.
Таблица session_connect_attrs
Приложения могут обеспечить признаки соединения ключа/значения, которые
передадут серверу во время соединения, используя функции C API
the mysql_options() и
mysql_options4().
session_connect_attrs содержит признаки соединения для всех
сеансов. Чтобы видеть признаки соединения сеансов только для Вашей
собственной учетной записи, загляните в
session_account_connect_attrs.
У
session_connect_attrs есть эти столбцы:
PROCESSLIST_ID
Идентификатор соединения для сеанса. ATTR_NAME
Название атрибута. ATTR_VALUE
Значение атрибута. ORDINAL_POSITION
Порядок, в котором признак был добавлен к набору признаков соединения.
У
session_connect_attrs есть эти индексы:
TRUNCATE TABLE не
позволен для
session_connect_attrs.
23.9.10.
Таблицы пользовательских переменных Performance Schema
Performance Schema обеспечивает таблицу
user_variables_by_thread, которая выставляет определяемые
пользователем переменные. Это переменные, определенные в пределах
определенного сеанса, и включают символ @, предшествующий имени.
У
user_variables_by_thread есть эти столбцы:
У
user_variables_by_thread есть эти индексы:
TRUNCATE TABLE не
позволен для
user_variables_by_thread.
23.9.11.
Таблицы репликации Performance Schema
Performance Schema обеспечивает таблицы, которые выставляют информацию о
репликации. Это подобно информации, доступной от
SHOW SLAVE STATUS,
но представление в табличной форме более доступно и обладает преимуществами
удобства и простоты использования:
Вывод SHOW SLAVE STATUS
полезен для визуального осмотра, но не для использования с
программным управлением. В отличие от этого, используя таблицы Performance
Schema, информация о ведомом состоянии может искаться, используя общие
запросы SELECT, включая комплексные
условия WHERE, соединения и т.д. - Результаты запроса могут быть сохранены в таблицах для дальнейшего
анализа или назначены переменным и таким образом
использоваться в хранимых процедурах.
- Таблицы репликации предоставляют лучшую диагностическую информацию. Для
мультипоточной ведомой работы
SHOW
SLAVE STATUS показывает все ошибки потоков, используя поля
Last_SQL_Errno и Last_SQL_Error,
таким образом, только последняя из этих ошибок видима, и информация может
быть потеряна. Таблицы репликации хранят ошибки на основе потока
без потери информации.
- Последняя замеченная транзакция видима в таблицах. Эта информация
недоступна из
SHOW SLAVE STATUS
.
- Разработчики, знакомые с интерфейсом Performance Schema, могут расширить
таблицы, чтобы обеспечить дополнительную информацию,
добавляя строки к таблицам.
Описание таблиц репликации
Performance Schema обеспечивает несколько связанных таблиц:
Таблицы, которые содержат информацию о присоединении ведомого
сервера к главному серверу:
Таблицы, которые содержат общую (не определенную для
потока) информацию о транзакци:
Таблицы, которые содержат информацию об определенных потоках,
ответственных за применение транзакций, полученных от ведущего устройства:
Таблицы, которые содержат информацию о членах группы:
Следующие разделы описывают каждую таблицу более подробно, включая
связь между столбцами, произведенными
SHOW SLAVE STATUS и столбцы таблицы репликации, в которых
появляется та же самая информация.
Остаток этого введения в таблицы описывает, как Performance Schema
заполняет их, и которые области от
SHOW SLAVE STATUS не представлены в таблицах.
Жизненный цикл таблиц
Performance Schema заполняет таблицы следующим образом:
Информация SHOW SLAVE STATUS
не в таблицах репликации
Информация в таблицах Performance Schema несколько отличается от
информации, доступной от SHOW SLAVE
STATUS потому? что таблицы ориентируются на использование
глобальных операционных идентификаторов (GTID), а не имен файла и позиций, и
они представляют серверные значения UUID, а не значения ID сервера.
Из-за этих различий, несколько столбцов
SHOW SLAVE STATUS не сохранены в Performance Schema или
представлены иным путем:
Следующие области обращаются к именам файла и
позициям и не сохранены:
Master_Log_File
Read_Master_Log_Pos
Relay_Log_File
Relay_Log_Pos
Relay_Master_Log_File
Exec_Master_Log_Pos
Until_Condition
Until_Log_File
Until_Log_Pos
- Поле
Master_Info_File не сохранено. Это обращается к
файлу master.info, который был заменен безопасными для
катастрофического отказа ведомыми таблицами.
- Следующие области основаны на
server_id, а не
server_uuid
и не сохранены:
Master_Server_Id
Replicate_Ignore_Server_Ids
- Поле
Skip_Counter основано на количестве
событий, а не GTID и не сохранено.
- Эти ошибочные поля псевдонимы для
Last_SQL_Errno и Last_SQL_Error,
таким образом, они не сохранены:
Last_Errno
Last_Error
В Performance Schema эта информация об ошибке доступна в столбцах
LAST_ERROR_NUMBER и LAST_ERROR_MESSAGE таблицы
replication_applier_status_by_coordinator
(и
replication_applier_status_by_worker,
если ведомое устройство является мультипоточным). Те таблицы предоставляют
более определенную информацию об ошибке для потока, чем доступна от
Last_Errno и Last_Error.
- Области, которые предоставляют информацию об опциях фильтрации командной
строки, не сохранены:
Replicate_Do_DB
Replicate_Ignore_DB
Replicate_Do_Table
Replicate_Ignore_Table
Replicate_Wild_Do_Table
Replicate_Wild_Ignore_Table
- Поля
Slave_IO_State и
Slave_SQL_Running_State не сохранены. Если нужно, эти значения
могут быть получены из списка процессов при использовании столбца
THREAD_ID соответствующей таблицы и присоединения к этому
столбца ID таблицы INFORMATION_SCHEMA
PROCESSLIST, чтобы
выбрать столбец STATE последней таблицы.
- Поле
Executed_Gtid_Set может показать большой набор с
большим количеством текста. Вместо этого таблицы Performance Schema
показывают GTID транзакций, которые в настоящее время применяются ведомым
устройством. Альтернативно, набор выполненного GTID может быть получен из
значения переменной
gtid_executed.
Seconds_Behind_Master и
Relay_Log_Space не сохранены.
Переменные состояния, перемещенные в таблицы
Начиная с MySQL 5.7.5, следующие переменные состояния (ранее доступные
через использование SHOW STATUS
) были перемещены в таблицы Perfomance Schema:
Эти переменные состояния теперь релевантны только, когда применяется
единственный канал репликации, потому что они сообщают о состоянии
только каналапо умолчанию. Когда
много каналов существует, используйте таблицы Performance Schema, описанные в
этом разделе, которые сообщают об этих переменных для
каждого существующего канала.
Каналы репликации
Первый столбец таблиц Performance Schema CHANNEL_NAME.
Это позволяет таблицам рассматриваться по каналам. Когда Вы используете
многократные каналы на ведомом устройстве, Вы можете фильтровать таблицы по
каналам, чтобы контролировать определенный канал. См. разделы
19.2.3 и
19.1.4.3.
23.9.11.1.
Таблица replication_connection_configuration
Эта таблица показывает параметры конфигурации, используемые ведомым
сервером для того, чтобы соединиться с главным сервером. Параметры,
сохраненные в таблице, могут быть изменены во время выполнения с помощью
CHANGE MASTER TO,
как обозначено в описаниях столбца.
По сравнению с
replication_connection_status,
replication_connection_configuration
изменяется менее часто. Это содержит значения, которые определяют, как
ведомое устройство соединяется с ведущим и которые остаются постоянными во
время соединения, тогда как
replication_connection_status
содержит значения, которые изменяются во время соединения.
У
replication_connection_configuration есть эти столбцы:
CHANNEL_NAME
Канал, который эта строка отображает. Всегда есть канал по умолчанию, и
больше каналов может быть добавлено. См.
раздел 19.2.3. HOST
Основной узел, с которым соединено ведомое устройство.
(CHANGE MASTER TO опция MASTER_HOST). PORT
Порт для связи с ведущим устройством. (CHANGE
MASTER TO опция MASTER_PORT). USER
Имя пользователя учетной записи для связи с ведущим устройством.
(CHANGE MASTER TO опция MASTER_USER). NETWORK_INTERFACE
Сетевой интерфейс для связи, если есть.
(CHANGE MASTER TO опция MASTER_BIND). AUTO_POSITION
1, если авторасположение используется, иначе 0.
(CHANGE MASTER TO опция MASTER_AUTO_POSITION). SSL_ALLOWED, SSL_CA_FILE,
SSL_CA_PATH, SSL_CERTIFICATE,
SSL_CIPHER, SSL_KEY,
SSL_VERIFY_SERVER_CERTIFICATE,
SSL_CRL_FILE, SSL_CRL_PATH
Эти столбцы показывают параметры SSL, используемые ведомым устройством,
чтобы соединиться с ведущим, если они есть.
SSL_ALLOWED имеет эти значения:
Опции 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 есть эти индексы:
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 |
23.9.11.2.
Таблица replication_connection_status
Эта таблица показывает текущий статус потока ввода/вывода, который
обрабатывает ведомое соединение сервера с главным сервером.
По сравнению с
replication_connection_configuration,
replication_connection_status изменяется более часто. Это содержит
значения, которые изменяются во время соединения, тогда как
replication_connection_configuration
содержит значения, которые определяют, как ведомое устройство соединяется с
ведущим и которые остаются постоянными во время соединения.
У
replication_connection_status есть эти столбцы:
CHANNEL_NAME
Канал, который эта строка отображает. Всегда есть канал по умолчанию, и
больше каналов может быть добавлено. См.
раздел 19.2.3. GROUP_NAME
Этот столбец сохранен для будущего использования. SOURCE_UUID
server_uuid
от ведущего устройства.
THREAD_ID
ID потока I/O. SERVICE_STATE
ON (поток существует и является активным или спящим),
OFF (поток больше не существует) или CONNECTING
(поток существует и соединяется с ведущим устройством).
RECEIVED_TRANSACTION_SET
Набор глобальных операционных ID (GTID), соответствующий всем транзакциям,
полученным этим ведомым устройством. Пустой, если GTID не используются. LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE
Код ошибки и сообщение об ошибке, которая заставила поток ввода/вывода
останавливаться. Код ошибки 0 и пустая строка не означают отсутствие ошибок.
Если LAST_ERROR_MESSAGE не пусто,
ошибочные значения также появляются в журнале ошибок ведомого устройства.
RESET MASTER или
RESET SLAVE
сбрасывает значения, показанные в этих столбцах.
LAST_ERROR_TIMESTAMP
timestamp в формате YYMMDD HH:MM:SS, который показывает,
когда последняя ошибка ввода/вывода имела место. LAST_HEARTBEAT_TIMESTAMP
timestamp в формате YYMMDD HH:MM:SS, который показывает,
когда последний сигнал биения был получен ведомым устройством. COUNT_RECEIVED_HEARTBEATS
Общее количество сигналов биения, которые ведомое устройство
получило с прошлого перезапуска или запроса
CHANGE MASTER TO.
У
replication_connection_status есть эти индексы:
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 |
23.9.11.3.
Таблица replication_applier_configuration
Таблица показывает параметры конфигурации, примененные ведомым сервером.
Параметры, сохраненные в таблице, могут быть изменены во время выполнения с
помощью CHANGE MASTER TO,
как обозначено в описаниях столбца.
У
replication_applier_configuration есть эти столбцы:
CHANNEL_NAME
Канал, который эта строка отображает. Всегда есть канал по умолчанию, и
больше каналов может быть добавлено. См.
раздел 19.2.3. DESIRED_DELAY
Число секунд, которые ведомое устройство должно
изолировать ведущее устройство. (CHANGE MASTER TO опция
MASTER_DELAY).
У
replication_applier_configuration есть эти индексы:
TRUNCATE TABLE не
позволен для
replication_applier_configuration.
Следующая таблица показывает связь между столбцами
replication_applier_configuration и
SHOW SLAVE STATUS.
Столбец replication_applier_configuration
|
Столбец SHOW SLAVE STATUS |
|---|
DESIRED_DELAY |
SQL_Delay |
23.9.11.4.
Таблица replication_applier_status
Эта таблица показывает текущее общее операционное состояние выполнения
на ведомом сервере.
Эта таблица предоставляет информацию об общих аспектах транзакции, которые
не являются определенными для любого вовлеченного потока. Определенная для
потока информация о статусе доступна в
replication_applier_status_by_coordinator (и
replication_applier_status_by_worker,
если ведомое устройство является мультипоточным).
У
replication_applier_status есть эти столбцы:
CHANNEL_NAME
Канал, который эта строка отображает. Всегда есть канал по умолчанию, и
больше каналов может быть добавлено. См.
раздел 19.2.3. SERVICE_STATE
Сохранено для будущего использования. REMAINING_DELAY
Если ведомое устройство ждет DESIRED_DELAY
секунд, так как ведущее устройство применяет случай, это поле содержит
оставшееся число секунд задержки. В других случаях это NULL.
DESIRED_DELAY сохранено в
replication_applier_configuration. COUNT_TRANSACTIONS_RETRIES
Показывает число повторений, которые были сделаны, потому что ведомый
поток SQL был не в состоянии применить транзакцию.
У
replication_applier_status есть эти индексы:
TRUNCATE TABLE не
позволен для
replication_applier_status.
Следующая таблица показывает связь между
replication_applier_status и
SHOW SLAVE STATUS.
Столбец replication_applier_status
|
Столбец SHOW SLAVE STATUS |
|---|
SERVICE_STATE | Нет |
REMAINING_DELAY |
SQL_Remaining_Delay |
23.9.11.5.
Таблица replication_applier_status_by_coordinator
Для мультипоточного ведомого устройства ведомое устройство использует
много рабочих потоков и поток координатора, чтобы управлять ими. Эта таблица
показывает состояние потока координатора. Для однопоточного ведомого
устройства эта таблица пуста. Для мультипоточного ведомого устройства
replication_applier_status_by_worker
показывает состояние рабочих потоков.
У
replication_applier_status_by_coordinator
есть эти столбцы:
CHANNEL_NAME
Канал, который эта строка отображает. Всегда есть канал по умолчанию, и
больше каналов может быть добавлено. См.
раздел 19.2.3. THREAD_ID
ID потока SQL/coordinator. SERVICE_STATE
ON (поток существует и является активным или спящим) или
OFF (поток больше не существует).
LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE
Код ошибки и сообщение об ошибке, которая заставила поток SQL/coordinator
останавливаться. Код ошибки 0 и пустая строка не означают, что ошибки нет.
Если LAST_ERROR_MESSAGE не пусто, ошибочные значения также
появляются в журнале ошибок ведомого устройства.
RESET MASTER или
RESET SLAVE
сбрасывает значения, показанные в этих столбцах.
Все коды ошибки и сообщения в LAST_ERROR_NUMBER и
LAST_ERROR_MESSAGE соответствуют ошибочным значениям,
перечисленным в разделе B.3.
LAST_ERROR_TIMESTAMP
timestamp в формате YYMMDD HH:MM:SS,
который показывает, когда последняя ошибка SQL/coordinator произошла.
У
replication_applier_status_by_coordinator
есть эти индексы:
TRUNCATE TABLE не
позволен для
replication_applier_status_by_coordinator.
Следующая таблица показывает связь между
replication_applier_status_by_coordinator и
SHOW SLAVE STATUS.
Столбец
replication_applier_status_by_coordinator |
Столбец SHOW SLAVE STATUS |
|---|
THREAD_ID | Нет |
SERVICE_STATE |
Slave_SQL_Running |
LAST_ERROR_NUMBER |
Last_SQL_Errno |
LAST_ERROR_MESSAGE |
Last_SQL_Error |
LAST_ERROR_TIMESTAMP |
Last_SQL_Error_Timestamp |
23.9.11.6.
Таблица replication_applier_status_by_worker
Если ведомое устройство не является мультипоточным, эта таблица показывает
состояние потока. Иначе, ведомое устройство использует много рабочих потоков
и поток координатора, чтобы управлять ими, и эта таблица показывает состояние
рабочих потоков. Для мультипоточного ведомого устройства
replication_applier_status_by_coordinator
показывает состояние потока координатора.
У replication_applier_status_by_worker
есть эти столбцы:
CHANNEL_NAME
Канал, который эта строка отображает. Всегда есть канал по умолчанию, и
больше каналов может быть добавлено. См.
раздел 19.2.3. WORKER_ID
Идентификатор рабочего (то же самое значение, как столбец
id в таблице mysql.slave_worker_info).
После STOP SLAVE
THREAD_ID становится NULL, но
WORKER_ID сохранено. THREAD_ID
ID рабочего потока. SERVICE_STATE
ON (поток существует и является активным или спящим) или
OFF (поток больше не существует).
LAST_SEEN_TRANSACTION
Транзакция, которую рабочий поток обработал последней.
Рабочий поток не обязательно применил эту транзакцию, потому что она могла
быть в процессе выполнения.
Если значение переменной
gtid_mode OFF, этот столбец ANONYMOUS,
указывая, что транзакции не имеют глобальных операционных идентификаторов
(GTID) и идентифицированы только файлом и позицией.
Если gtid_mode
ON, значение столбца определено следующим образом:
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 есть эти индексы:
TRUNCATE TABLE не
позволен для
replication_applier_status_by_worker.
Следующая таблица показывает связь между
replication_applier_status_by_worker и
SHOW SLAVE STATUS.
Столбец replication_applier_status_by_worker
|
Столбец SHOW SLAVE STATUS |
|---|
WORKER_ID | Нет |
THREAD_ID | Нет |
SERVICE_STATE | Нет |
LAST_SEEN_TRANSACTION | Нет |
LAST_ERROR_NUMBER |
Last_SQL_Errno |
LAST_ERROR_MESSAGE |
Last_SQL_Error |
LAST_ERROR_TIMESTAMP |
Last_SQL_Error_Timestamp |
23.9.11.7.
Таблица replication_group_members
Эта таблица показывает сеть и информацию о статусе для
членов группы репликации.
Таблица replication_group_members имеет следующие столбцы:
CHANNEL_NAME
Название группового канала. MEMBER_ID
Идентификатор для этого участника, то же самое как сервер UUID. MEMBER_HOST
Сетевой адрес этого участника (имя хоста или IP-адрес). MEMBER_PORT
Порт, на котором слушает сервер. MEMBER_STATE
Текущее состояние этого участника, может быть любое из следующего:
TRUNCATE TABLE не
позволен для
replication_group_members.
23.9.11.8.
Таблица replication_group_member_stats
Эта таблица показывает статистическую информацию для членов группы.
У replication_group_member_stats есть следующие столбцы:
CHANNEL_NAME
Название группового канала. VIEW_ID
Идентификатор текущего представления для этой группы. MEMBER_ID
Идентификатор для этого участника, то же самое как сервер UUID. COUNT_TRANSACTIONS_IN_QUEUE
Число транзакций в ожидании. COUNT_TRANSACTIONS_CHECKED
Число транзакций уже удостоверено этим участником. COUNT_CONFLICTS_DETECTED
Число транзакций, которые не были удостоверены. COUNT_TRANSACTIONS_VALIDATING
Число транзакций, с которыми может выполниться удостоверение,
но не был собран мусор. TRANSACTIONS_COMMITTED_ALL_MEMBERS
Набор устойчивых групповых транзакций. LAST_CONFLICT_FREE_TRANSACTION
Последняя транзакция, удостоверенная без конфликтов.
TRUNCATE TABLE не
позволен для
replication_group_member_stats.
23.9.12.
Таблицы блокировки Performance Schema
Performance Schema выставляет информацию о блокировке через эти таблицы:
Следующие разделы описывают эти таблицы более подробно.
23.9.12.1. Таблица data_locks
Таблица data_locks
показывает блокировки данных, которые введены и требуются. Для информации о
том, какие запросы блокировки заблокированы введеными блокировками, см.
раздел 23.9.12.2.
Обе таблицы были добавлены в MySQL 8.0.1.
Данные в качестве примера:
mysql> SELECT * FROM data_locks\G
*************************** 1. row ***************************
ENGINE: INNODB
ENGINE_LOCK_ID: 4140:74
ENGINE_TRANSACTION_ID: 4140
THREAD_ID: 37
EVENT_ID: 9
OBJECT_SCHEMA: test
OBJECT_NAME: t1
PARTITION_NAME: NULL
SUBPARTITION_NAME: NULL
INDEX_NAME: NULL
OBJECT_INSTANCE_BEGIN: 140489308280888
LOCK_TYPE: TABLE
LOCK_MODE: IX
LOCK_STATUS: GRANTED
LOCK_DATA: NULL
*************************** 2. row ***************************
ENGINE: INNODB
ENGINE_LOCK_ID: 4140:66:5:1
ENGINE_TRANSACTION_ID: 4140
THREAD_ID: 37
EVENT_ID: 9
OBJECT_SCHEMA: test
OBJECT_NAME: t1
PARTITION_NAME: NULL
SUBPARTITION_NAME: NULL
INDEX_NAME: GEN_CLUST_INDEX
OBJECT_INSTANCE_BEGIN: 140489320307736
LOCK_TYPE: RECORD
LOCK_MODE: X
LOCK_STATUS: GRANTED
LOCK_DATA: supremum pseudo-record
В отличие от большинства сбора данных Performance Schema,
нет никаких инструментов для того, чтобы управлять, собрана ли информация
о блокировках данных, или системных переменных для того, чтобы управлять
табличными размерами блокировки данных. Performance Schema собирает
информацию, которая уже доступна в сервере, таким образом нет никаких
издержек памяти или центрального процессора, чтобы произвести эту информацию
или потребности в параметрах, которые управляют ее сбором.
Используйте data_locks
, чтобы помочь диагностировать исполнительные проблемы, которые
происходят во времена тяжелой параллельной загрузки. Для InnoDB
см. обсуждение этой темы в
разделе 16.14.2
.
У data_locks
есть эти столбцы:
ENGINE:
Механизм хранения, который держит или просил блокировку. ENGINE_LOCK_ID:
ID блокировки. Кортежи зачений
(ENGINE_LOCK_ID, ENGINE) уникальны.
Форматы ID блокировки являются внутренними и подлежат изменению в любое
время. Приложения не должны положиться на ID
блокировки, имеющие особый формат. ENGINE_TRANSACTION_ID:
Внутренний ID механизма хранения транзакции, которая просила блокировку.
Для InnoDB, чтобы получить детали о транзакции,
присоединитесь к этому столбцу с TRX_ID из
INFORMATION_SCHEMA
INNODB_TRX. THREAD_ID:
ID потока, которому принадлежит блокировка. Чтобы получить детали о
потоке, присоединитесь к этому столбцу с THREAD_ID из
Performance Schema threads
. EVENT_ID:
Исполнительный случай, который вызвал блокировку. Кортежи
(THREAD_ID, EVENT_ID) неявно идентифицируют
родительский случай в других таблицах Performance Schema:
Чтобы получить детали о родительском случае, соедините столбцы
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
есть эти индексы:
TRUNCATE TABLE не
позволен для data_locks
.
23.9.12.2. Таблица data_lock_waits
Таблица data_lock_waits
осуществляет отношения, показывая, какие данные запирают запросы
в data_locks,
сдерживая блокировки данных. Сдержанные блокировки в
data_locks
отобразятся в
data_lock_waits только, если они блокируют некоторый запрос
блокировки. Обе таблицы были добавлены в MySQL 8.0.1.
Эта информация позволяет Вам понять зависимости от блокировки данных
между сеансами. Таблица выставляет не только, которые блокировки держат
сеанс, или какую блокировку ждет транзакция, но и то, какая сессия или
транзакция в настоящее время проводят ту блокировку.
Блокировка данных в качестве примера:
mysql> SELECT * FROM data_lock_waits\G
*************************** 1. row ***************************
ENGINE: INNODB
REQUESTING_ENGINE_LOCK_ID: 4141:66:5:2
REQUESTING_ENGINE_TRANSACTION_ID: 4141
REQUESTING_THREAD_ID: 38
REQUESTING_EVENT_ID: 11
REQUESTING_OBJECT_INSTANCE_BEGIN: 140489320441368
BLOCKING_ENGINE_LOCK_ID: 4140:66:5:2
BLOCKING_ENGINE_TRANSACTION_ID: 4140
BLOCKING_THREAD_ID: 37
BLOCKING_EVENT_ID: 9
BLOCKING_OBJECT_INSTANCE_BEGIN: 140489320307736
В отличие от большинства сбора данных Performance Schema,
нет никаких инструментов для того, чтобы управлять, собрана ли информация
о блокировках данных, или системных переменных для того, чтобы управлять
табличными размерами блокировки данных. Performance Schema собирает
информацию, которая уже доступна в сервере, таким образом нет никаких
издержек памяти или центрального процессора, чтобы произвести эту информацию
или потребности в параметрах, которые управляют ее сбором.
Используйте data_locks
, чтобы помочь диагностировать исполнительные проблемы, которые
происходят во времена тяжелой параллельной загрузки. Для InnoDB
см. обсуждение этой темы в
разделе 16.14.2
.
Поскольку столбцы в
data_lock_waits подобны столбцам в
data_locks,
описания столбцов здесь сокращены. Для более подробных описаний столбцов см.
раздел 23.9.12.1.
У data_lock_waits
есть эти столбцы:
ENGINE
Механизм хранения, который запросил блокировку. REQUESTING_ENGINE_LOCK_ID
ID блокировки, которую требует механизм хранения. Чтобы получить детали о
блокировке, присоедините к этому столбцу LOCK_ID из
data_locks. REQUESTING_ENGINE_TRANSACTION_ID
Внутренний ID механизма хранения транзакции, который запросил блокировку.
REQUESTING_THREAD_ID
ID потока сеанса, который запросил блокировку. REQUESTING_EVENT_ID
Случай Performance Schema, который вызвал запрос блокировки в сеансе,
который запросил блокировку. REQUESTING_OBJECT_INSTANCE_BEGIN
Адрес в памяти о требуемой блокировке. BLOCKING_ENGINE_LOCK_ID
ID блокировки. Чтобы получить детали о блокировке, присоединитесь к этому
столбцу с LOCK_ID из
data_locks. BLOCKING_ENGINE_TRANSACTION_ID
Внутренний ID механизма хранения транзакции, которая держит блокировку.
BLOCKING_THREAD_ID
ID потока сеанса, который держит блокировку. BLOCKING_EVENT_ID
Случай Performance Schema, который вызвал блокировку в сеансе. BLOCKING_OBJECT_INSTANCE_BEGIN
Адрес в памяти о блокировке.
У
data_lock_waits есть эти индексы:
TRUNCATE TABLE не
позволен для data_lock_waits
.
23.9.12.3. Таблица metadata_locks
Performance Schema выставляет информацию о блокировке метаданных через
metadata_locks:
Эта информация позволяет Вам понять зависимости от блокировки метаданных
между сеансами. Вы можете видеть не только, которые блокировки сеанс ждет, но
и какая сессия в настоящее время проводит эту блокировку.
metadata_locks
только для чтения и не может быть обновлена. Это задано по умолчанию, чтобы
сконфигурировать табличный размер, установите системную переменную
performance_schema_max_metadata_locks при запуске сервера.
Инструментовка блокировки метаданных отключена по умолчанию. Чтобы
включить, запустите инструмент wait/lock/metadata/sql/mdl в
setup_instruments
.
Performance Schema поддерживает табличный контент
metadata_locks
следующим образом, используя столбец LOCK_STATUS, чтобы указать
на состояние каждой блокировки:
У metadata_locks
есть эти столбцы:
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
есть эти индексы:
TRUNCATE TABLE не
позволен для metadata_locks
.
23.9.12.4. Таблица table_handles
Performance Schema выставляет табличную информацию о блокировке через
table_handles,
чтобы показать табличную блокировку в настоящее время в действительности для
каждого открытого табличного дескриптора.
table_handles
сообщает, что зарегистрировано табличной инструментовкой блокировки. Это
показывает, какая таблица открыта сервером, как она
заблокирована и которым сеансом.
table_handles
только для чтения и не может быть обновлена. Это задано по умолчанию, чтобы
сконфигурировать табличный размер, установите переменную
performance_schema_max_table_handles при запуске сервера.
У table_handles
есть эти столбцы:
OBJECT_TYPE
Таблица открылась табличным дескриптором. OBJECT_SCHEMA
Схема, которая содержит объект. OBJECT_NAME
Название инструментованного объекта. OBJECT_INSTANCE_BEGIN
Табличный дескриптор в памяти. OWNER_THREAD_ID
Поток, имеющий табличный дескриптор. OWNER_EVENT_ID
Случай, который заставил табличный дескриптор быть открытым. INTERNAL_LOCK
Табличная блокировка на уровне SQL. Значение одно из
READ, READ WITH SHARED LOCKS,
READ HIGH PRIORITY, READ NO INSERT,
WRITE ALLOW WRITE, WRITE CONCURRENT INSERT,
WRITE LOW PRIORITY или WRITE.
Для информации об этих типах блокировки см. файл исходных текстов
include/thr_lock.h. EXTERNAL_LOCK
Табличная блокировка на уровне механизма хранения. Значение одно из
READ EXTERNAL или WRITE EXTERNAL.
У table_handles
есть эти индексы:
TRUNCATE TABLE не
позволен для table_handles
.
23.9.13.
Системные таблицы переменных Performance Schema
Значение переменной
show_compatibility_56 затрагивает информацию, доступную из
таблиц
global_variables,
session_variables и
variables_by_thread, описанных здесь
(variables_info
не затронута). Для деталей см. описание той переменной в
разделе 6.1.5.
MySQL server поддерживает много системных переменных, которые указывают,
как он сконфигурирован (см.
раздел 6.1.5). Системная информация о переменных доступна в этих
таблицах Performance Schema:
Таблицы переменной сеанса
(
session_variables,
variables_by_thread) содержат информацию только для активных
сеансов, не законченных сеансов.
TRUNCATE TABLE не
допускается для системных таблиц переменных Performance Schema.
У
global_variables и
session_variables есть эти столбцы:
VARIABLE_NAME
Системное имя переменной. VARIABLE_VALUE
Системное значение переменной. Для
global_variables этот столбец содержит глобальное значение. Для
session_variables этот столбец содержит значение переменной
для текущего сеанса.
У
global_variables и
session_variables есть индексы:
У
variables_by_thread есть эти столбцы:
THREAD_ID
Идентификатор потока сеанса, в котором определена системная переменная.
VARIABLE_NAME
Системное имя переменной. VARIABLE_VALUE
Значение переменной сеанса для сеанса, названного в столбце
THREAD_ID.
У
variables_by_thread есть эти индексы:
variables_by_thread содержит системную информацию о переменных
только о потоках переднего плана. Если не все потоки будут инструментованы
Performance Schema, эта таблица пропустит некоторые строки. В этом случае
переменная состояния
Performance_schema_thread_instances_lost
будет больше, чем ноль.
23.9.13.1. Таблица variables_info
variables_info
для каждой системной переменной показывает источник, из которого это было
последний раз установлено, и его диапазон значений.
У variables_info
есть эти столбцы:
VARIABLE_NAME
Имя переменной. VARIABLE_SOURCE
Источник, из которого была последний раз установлена переменная:
COMMAND_LINE
Переменная была установлена из командной строки. COMPILED
У переменной есть значение по умолчанию. COMPILED это
значение, используемое для переменных, не заданных любым другим путем. DYNAMIC
Переменная была установлена во время выполнения. Это включает задание
переменных в пределах файлов, определенных, используя опцию
--init-file.
EXPLICIT
Переменная была установлена из файла опции, названного в опции
--defaults-file
. EXTRA
Переменная была установлена из файла опции, названного в опции
--defaults-extra-file. GLOBAL
Переменная была установлена из глобального файла опции. Это включает файлы
опции, не покрытые EXPLICIT, EXTRA,
LOGIN, PERSISTED,
SERVER или USER. LOGIN
Переменная была установлена из определенного для пользователя файла входа
в систему (~/.mylogin.cnf). PERSISTED
Переменная была установлена из определенного для сервера файла опций
mysqld-auto.cnf. Ни у какой строки нет этого значения, если
сервер был запущен с выключенной
persisted_globals_load. SERVER
Переменная была установлена из определенного для сервера файла опций
$MYSQL_HOME/my.cnf USER
Переменная была установлена из определенного для пользователя файла опций
~/.my.cnf.
VARIABLE_PATH
Если переменная была установлена из файла опции,
VARIABLE_PATH путь к этому файлу. Иначе значение пустая строка.
MIN_VALUE, MAX_VALUE
Минимальные и максимальные разрешенные значения для переменной. Оба 0 для
переменных, у которых нет таких значений (то есть, переменные, которые
не являются числовыми).
TRUNCATE TABLE не
позволен для variables_info
.
Если переменная с VARIABLE_SOURCE, кроме DYNAMIC
установлена во время выполнения, VARIABLE_SOURCE становится
DYNAMIC, а VARIABLE_PATH пустой строкой.
Системная переменная, у которой есть только значение сеанса (такая как
debug_sync)
не может быть установлена при запуске. Для системных переменных только для
сеанса VARIABLE_SOURCE может быть только
COMPILED или DYNAMIC.
Если у системной переменной есть неожиданное
VARIABLE_SOURCE,
рассмотрите свой метод запуска сервера. Например,
mysqld_safe
читает файлы опции и передает определенные опции, которые он находит там
как часть командной строки, которую он использует, чтобы запустить
mysqld.
Следовательно, некоторые системные переменные, которые Вы устанавливаете в
файлах опции, могли бы отобразиться в
variables_info как
COMMAND_LINE вместо GLOBAL или SERVER.
Некоторые типовые запросы, которые используют
variables_info:
Показать переменные из командной строки:
mysql> SELECT VARIABLE_NAME FROM variables_info
WHERE VARIABLE_SOURCE = 'COMMAND_LINE'
ORDER BY VARIABLE_NAME;
+---------------+
| VARIABLE_NAME |
+---------------+
| basedir |
| datadir |
| log_error |
| pid_file |
| plugin_dir |
| port |
+---------------+
- Показать переменные из постоянного хранения:
mysql> SELECT VARIABLE_NAME FROM variables_info
WHERE VARIABLE_SOURCE = 'PERSISTED'
ORDER BY VARIABLE_NAME;
+--------------------------+
| VARIABLE_NAME |
+--------------------------+
| event_scheduler |
| expire_logs_days |
| max_connections |
| validate_password_policy |
+--------------------------+
- Соединение
variables_info
с
global_variables, чтобы вывести на экран текущие значения
сохраненных переменных, вместе с их диапазоном значений:
mysql> SELECT VI.VARIABLE_NAME, GV.VARIABLE_VALUE,
VI.MIN_VALUE,VI.MAX_VALUE FROM variables_info AS VI
INNER JOIN global_variables AS GV USING(VARIABLE_NAME)
WHERE VI.VARIABLE_SOURCE = 'PERSISTED'
ORDER BY VARIABLE_NAME;
+--------------------------+----------------+-----------+-----------+
| VARIABLE_NAME | VARIABLE_VALUE | MIN_VALUE | MAX_VALUE |
+--------------------------+----------------+-----------+-----------+
| event_scheduler | ON | 0 | 0 |
| expire_logs_days | 7 | 0 | 99 |
| max_connections | 200 | 1 | 100000 |
| validate_password_policy | STRONG | 0 | 0 |
+--------------------------+----------------+-----------+-----------+
23.9.14.
Таблицы состояния переменных Performance Schema
Значение переменной
show_compatibility_56 затрагивает информацию, доступную из
таблиц, описанных здесь. Для деталей см. описание этой переменной в
разделе 6.1.5.
Сервер MySQL поддерживает много переменных состояния, которые
предоставляют информацию о его работе (см.
раздел 6.1.7). Информация о
переменной состояния доступна в этих таблицах Performance Schema:
Есть также сводные таблицы, которые предоставляют информацию о переменных
состояния, связанные учетной записью, именем хоста и именем пользователя. См.
раздел 23.9.15.11.
Таблицы переменной сеанса
(
session_status,
status_by_thread) содержат информацию только для активных, а
не законченных сеансов.
Performance Schema собирает статистические данные для глобальных
переменных состояния только для потоков для которых значение
INSTRUMENTED YES в
threads.
Статистические данные для переменных состояния сеанса всегда собираются,
независимо от значения INSTRUMENTED.
Performance Schema не собирает статистические данные для
переменных состояния Com_xxx в
таблицах переменных состояния. Чтобы получить глобальное и сессионное
количество выполнения запросов за сеанс, используйте
events_statements_summary_global_by_event_name
и
events_statements_summary_by_thread_by_event_name
, соответственно. Например:
SELECT EVENT_NAME, COUNT_STAR
FROM events_statements_summary_global_by_event_name
WHERE EVENT_NAME LIKE 'statement/sql/%';
У
global_status и
session_status есть эти столбцы:
У
global_status и
session_status есть индексы:
status_by_thread содержит состояние каждого активного потока. У
нее есть эти столбцы:
THREAD_ID
Идентификатор потока сеанса, в котором определена переменная состояния.
VARIABLE_NAME
Имя переменной состояния. VARIABLE_VALUE
Значение переменной сеанса для сеанса,
названного в столбце THREAD_ID.
У
status_by_thread есть эти индексы:
status_by_thread содержит информацию о переменной состояния только
о потоках переднего плана. Если переменная
performance_schema_max_thread_instances не автомасштабируется
(установлена в -1), и максимальное разрешенное число инструментованных
объектов потока не больше, чем число фоновых потоков, таблица будет пуста.
Performance Schema поддерживает
TRUNCATE TABLE для таблиц переменных состояния следующим образом:
global_status: Сбрасывает потоки, учетные записи, узлы и
пользователей. Сбрасывает глобальные переменные состояния кроме тех, которые
никогда не сбрасывает сервер.
session_status: Не поддерживается.
status_by_thread: Состояние совокупностей для всех потоков к
глобальному состоянию и состоянию учетной записи, затем сбрасывает состояние
потока. Если статистические данные учетной записи не собраны, состояние
сеанса добавлено к состояниям хоста и пользователя, если они собраны.
Учетная запись, узел и пользовательская статистика не собраны, если
переменные
performance_schema_accounts_size,
performance_schema_hosts_size и
performance_schema_users_size, соответственно, установлены в 0.
FLUSH STATUS
добавляет состояние сеанса из всех активных сеансов в глобальные переменные
состояния, сбрасывает состояние всех активных сеансов и сбрасывает значения
состояния учетной записи, узла и пользователя от разъединенных сеансов.
23.9.15.
Сводные таблицы Performance Schema
Сводные таблицы предоставляют соединенную информацию для законченных
событий в течение долгого времени. Таблицы в этой группе суммируют данные
событий по-разному.
Резюме событий ожидания:
Резюме этапа:
Резюме запросов:
Операционные резюме:
Резюме ожидания объекта:
Резюме ввода/вывода файла:
Табличный ввод / вывод и ожидание блокировки:
Резюме сокета:
Резюме памяти:
Резюме ошибок:
Резюме переменных состояния:
У каждой сводной таблицы есть группирующиеся столбцы, которые определяют,
как сгруппировать данные, которые будут соединены, и сводные столбцы, которые
содержат соединенные значения. Таблицы, которые суммируют события похожими
способами, имеют подобные наборы сводных столбцов и отличаются только по
группирующимся столбцам, используемым, чтобы определить,
как соединены события.
Сводные таблицы могут быть усечены с
TRUNCATE TABLE.
Вообще, эффект состоит в том, чтобы сбросить сводные столбцы к 0 или
NULL, а не удалить строки. Это позволяет очистить
собранные значения. Это могло бы быть полезно, например, после того, как Вы
произвели изменение конфигурации во время выполнения. Исключения к этому
поведению усечения отмечены в отдельных разделах сводной таблицы.
23.9.15.1.
Сводные таблицы событий ожидания
Performance Schema поддерживает таблицы для того, чтобы собрать
актуальные и недавние события.
раздел 23.9.4
описывает события, на которых базируются резюме.
Пример информации о резюме событий:
mysql> SELECT * FROM events_waits_summary_global_by_event_name\G
...
*************************** 6. row ***************************
EVENT_NAME: wait/synch/mutex/sql/BINARY_LOG::LOCK_index
COUNT_STAR: 8
SUM_TIMER_WAIT: 2119302
MIN_TIMER_WAIT: 196092
AVG_TIMER_WAIT: 264912
MAX_TIMER_WAIT: 569421
...
*************************** 9. row ***************************
EVENT_NAME: wait/synch/mutex/sql/hash_filo::lock
COUNT_STAR: 69
SUM_TIMER_WAIT: 16848828
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 244185
MAX_TIMER_WAIT: 735345
...
У сводной таблицы событий есть один или более группирующихся столбцов,
чтобы указать как табличные события объединяются. Имена событий обращаются к
названиям инструментов событий в
setup_instruments
.
У сводной таблицы событий есть эти сводные столбцы,
содержащие соединенные значения:
COUNT_STAR
Число полученных в итоге событий. Это значение включает все события. SUM_TIMER_WAIT
Общее количество времени ожидания полученных в итоге рассчитанных событий.
Это значение вычислено только для рассчитанных событий, потому что у
нерассчитанных событий время ожидания NULL. The
То же самое истина для других значений
xxx_TIMER_WAIT MIN_TIMER_WAIT
Минимум времени ожидания полученных в итоге рассчитанных событий. AVG_TIMER_WAIT
Среднее время ожидания полученных в итоге рассчитанных событий. MAX_TIMER_WAIT
Максимум времени ожидания полученных в итоге рассчитанных событий.
Сводные таблицы событий имеют индексы:
TRUNCATE TABLE позволен
на сводных таблицах. Это имеет эффекты:
Для сводных таблиц, не соединенных с учетной записью, узлом или
пользователем, усечение сбрасывает сводные столбцы к нолю вместо того,
чтобы удалить строки. - Для сводных таблиц, соединенных с учетной записью, узлом или
пользователем, усечение удаляет строки для учетных записей, узлов или
пользователей без соединений и сбрасывает сводные столбцы к нолю
для остающихся строк.
Кроме того, каждая сводная таблица, которая соединена с учетной записью,
узлом, пользователем или потоком является неявно усеченной усечением таблицы
соединения, от которой зависит или усечением
events_waits_summary_global_by_event_name.
23.9.15.2. Сводные таблицы этапа
Performance Schema поддерживает таблицы для того, чтобы собрать текущие и
недавние события этапа.
Раздел 23.9.5 описывает события, на которых базируются резюме этапа.
Информация о резюме этапа событий в качестве примера:
mysql> SELECT * FROM events_stages_summary_global_by_event_name\G
...
*************************** 5. row ***************************
EVENT_NAME: stage/sql/checking permissions
COUNT_STAR: 57
SUM_TIMER_WAIT: 26501888880
MIN_TIMER_WAIT: 7317456
AVG_TIMER_WAIT: 464945295
MAX_TIMER_WAIT: 12858936792
...
*************************** 9. row ***************************
EVENT_NAME: stage/sql/closing tables
COUNT_STAR: 37
SUM_TIMER_WAIT: 662606568
MIN_TIMER_WAIT: 1593864
AVG_TIMER_WAIT: 17907891
MAX_TIMER_WAIT: 437977248
...
У каждой сводной таблицы этапа есть один или более группирующихся
столбцов, чтобы указать как табличные события объединяются.
Имена событий обращаются к названиям инструментов событий в
setup_instruments
.
У каждой сводной таблицы этапа есть эти сводные столбцы,
содержащие соединенные значения: COUNT_STAR,
SUM_TIMER_WAIT, MIN_TIMER_WAIT,
AVG_TIMER_WAIT и MAX_TIMER_WAIT.
Эти столбцы походят на столбцы с теми же именами в сводных таблицах событий
ожидания (см. раздел 23.9.15.1),
за исключением того, что события совокупности сводных таблиц этапа из
events_stages_current
вместо
events_waits_current
.
Сводные таблицы этапа имеют индексы:
TRUNCATE TABLE позволен
на сводных таблицах этапа. Это имеет эффекты:
Для сводных таблиц, не соединенных с учетной записью, узлом или
пользователем, усечение сбрасывает сводные столбцы к нолю вместо того,
чтобы удалить строки. - Для сводных таблиц, соединенных с учетной записью, узлом или
пользователем, усечение удаляет строки для учетных записей, узлов или
пользователей без соединений и сбрасывает сводные столбцы к нолю
для остающихся строк.
Кроме того, каждая сводная таблица этапа, которая соединена с учетной
записью, узлом, пользователем или потоком, является неявно усеченной
усечением таблицы, от которой это зависит, или усечением
events_stages_summary_global_by_event_name.
23.9.15.3.
Сводные таблицы запросов
Performance Schema поддерживает таблицы для того, чтобы собрать текущие
и недавние события запросов.
Раздел 23.9.6
описывает события, на которых базируются резюме запросов.
Информация о резюме запросов событий в качестве примера:
mysql> SELECT * FROM events_statements_summary_global_by_event_name\G
*************************** 1. row ***************************
EVENT_NAME: statement/sql/select
COUNT_STAR: 25
SUM_TIMER_WAIT: 1535983999000
MIN_TIMER_WAIT: 209823000
AVG_TIMER_WAIT: 61439359000
MAX_TIMER_WAIT: 1363397650000
SUM_LOCK_TIME: 20186000000
SUM_ERRORS: 0
SUM_WARNINGS: 0
SUM_ROWS_AFFECTED: 0
SUM_ROWS_SENT: 388
SUM_ROWS_EXAMINED: 370
SUM_CREATED_TMP_DISK_TABLES: 0
SUM_CREATED_TMP_TABLES: 0
SUM_SELECT_FULL_JOIN: 0
SUM_SELECT_FULL_RANGE_JOIN: 0
SUM_SELECT_RANGE: 0
SUM_SELECT_RANGE_CHECK: 0
SUM_SELECT_SCAN: 6
SUM_SORT_MERGE_PASSES: 0
SUM_SORT_RANGE: 0
SUM_SORT_ROWS: 0
SUM_SORT_SCAN: 0
SUM_NO_INDEX_USED: 6
SUM_NO_GOOD_INDEX_USED: 0
...
У каждой сводной таблицы запросы есть один или более группирующихся
столбцов, чтобы указать как табличные события объединяются. Имена событий
обращаются к названиям инструментов событий в
setup_instruments
.
У каждой сводной таблицы запросов есть эти сводные столбцы, содержащие
соединенные значения (с исключениями, как отмечено):
У
events_statements_summary_by_digest
есть эти дополнительные сводные столбцы:
FIRST_SEEN_TIMESTAMP,
LAST_SEEN_TIMESTAMP
Времена, в которые запрос с данным значением обзора был
замечен в первый и последний раз.
У
events_statements_summary_by_program
есть эти дополнительные сводные столбцы:
COUNT_STATEMENTS, SUM_STATEMENTS_WAIT,
MIN_STATEMENTS_WAIT, AVG_STATEMENTS_WAIT,
MAX_STATEMENTS_WAIT
Статистика о вложенных запросах во время выполнения сохраненной программы.
У
prepared_statements_instances
есть эти дополнительные сводные столбцы:
COUNT_EXECUTE, SUM_TIMER_EXECUTE,
MIN_TIMER_EXECUTE, AVG_TIMER_EXECUTE,
MAX_TIMER_EXECUTE
Соединенная статистика для выполнения готового запроса.
Сводные таблицы запросы имеют индексы:
TRUNCATE TABLE позволен
для сводных таблиц запросов. Это имеет эффекты:
Кроме того, каждая сводная таблица запросов, которая соединена с учетной
записью, узлом, пользователем или потоком, является неявно усеченной
усечением таблицы соединения, от которой зависит, или усечением
events_statements_summary_global_by_event_name.
Правила агрегации обзоров запросов
Если потребитель включен statement_digest, агрегация в
events_statements_summary_by_digest
происходит следующим образом, когда запрос завершается. Агрегация основана на
значении DIGEST, вычисленном для запроса.
Если строка
events_statements_summary_by_digest уже существует со значением
обзора для запроса, который только что завершился, статистические данные для
запроса присоединены к этой строке. Столбец LAST_SEEN
обновлен к текущему времени. - Если ни у какой строки нет значения обзора для запроса, который только
что завершился, и таблица не полна, новая строка создается для запроса.
FIRST_SEEN и LAST_SEEN
инициализированы с текущим временем.
- Если ни у какой строки нет значения обзора для запроса, который только
что завершился, и таблица полна, статистические данные для запроса
добавлены к специальной строке catch-all с
DIGEST = NULL,
который создается в случае необходимости. Если строка создается, столбцы
FIRST_SEEN и LAST_SEEN
инициализированы с текущим временем. Иначе LAST_SEEN
обновлен с текущим временем.
Строка с DIGEST = NULL поддержана, потому что у
таблиц Performance Schema есть максимальный размер из-за ограничений памяти.
Строка DIGEST = NULL разрешает обзоры, которые не
соответствуют другим строкам, которые будут посчитаны, даже если сводная
таблица полна. Эта строка помогает Вам оценить, является ли
резюме обзора представительным:
Строка DIGEST = NULL, у которой есть
значение COUNT_STAR, которое представляет 5% всех обзоров,
показывает, что сводная таблица обзора является очень представительной:
другие строки покрывают 95% замеченных запросов. - Строка
DIGEST = NULL, у которой есть
значение COUNT_STAR, которое представляет 50% всех обзоров,
показывает, что сводная таблица обзора не является очень представительной:
другие строки покрывают только половину замеченных запросов. Наиболее
вероятно DBA должен увеличить максимальный табличный размер так, чтобы больше
строк включилось, а строка DIGEST = NULL
была бы посчитана, используя более определенные строки вместо этого.
Чтобы сделать это, установите системную переменную
performance_schema_digests_size к большему значению при запуске
сервера. Размер значения по умолчанию 200.
Поведение инструментовки сохраненной программы
Для типов сохраненных программ, для которых инструментовка включена в
setup_objects,
events_statements_summary_by_program
поддерживает статистику для сохраненных программ следующим образом:
23.9.15.4.
Операционные сводные таблицы
Performance Schema поддерживает таблицы для того, чтобы собрать текущие и
недавние операционные события.
Раздел 23.9.7
описывает события, на которых базируются операционные резюме.
Операционная информация о резюме событий в качестве примера:
mysql> SELECT * FROM events_transactions_summary_global_by_event_name
LIMIT 1\G
*************************** 1. row ***************************
EVENT_NAME: transaction
COUNT_STAR: 5
SUM_TIMER_WAIT: 19550092000
MIN_TIMER_WAIT: 2954148000
AVG_TIMER_WAIT: 3910018000
MAX_TIMER_WAIT: 5486275000
COUNT_READ_WRITE: 5
SUM_TIMER_READ_WRITE: 19550092000
MIN_TIMER_READ_WRITE: 2954148000
AVG_TIMER_READ_WRITE: 3910018000
MAX_TIMER_READ_WRITE: 5486275000
COUNT_READ_ONLY: 0
SUM_TIMER_READ_ONLY: 0
MIN_TIMER_READ_ONLY: 0
AVG_TIMER_READ_ONLY: 0
MAX_TIMER_READ_ONLY: 0
У каждой операционной сводной таблицы есть один или более группирующихся
столбцов, чтобы указать как табличные события объединяются.
Имена событий обращаются к названиям инструментов событий в
setup_instruments
.
У каждой операционной сводной таблицы есть эти сводные столбцы,
содержащие соединенные значения:
COUNT_STAR, SUM_TIMER_WAIT,
MIN_TIMER_WAIT, AVG_TIMER_WAIT,
MAX_TIMER_WAIT
Эти столбцы походят на столбцы с теми же самыми именами в
сводных таблицах событий ожидания за исключением того, что операционные
события сводных таблиц из
events_transactions_current вместо
events_waits_current
. Эти столбцы суммируют транзакции только для
чтения и чтения-записи. COUNT_READ_WRITE, SUM_TIMER_READ_WRITE,
MIN_TIMER_READ_WRITE, AVG_TIMER_READ_WRITE,
MAX_TIMER_READ_WRITE
Они подобны COUNT_STAR и
xxx_TIMER_WAIT COUNT_READ_ONLY, SUM_TIMER_READ_ONLY,
MIN_TIMER_READ_ONLY, AVG_TIMER_READ_ONLY,
MAX_TIMER_READ_ONLY
Они подобны COUNT_STAR и
xxx_TIMER_WAIT
Операционные сводные таблицы имеют индексы:
TRUNCATE TABLE позволен
для операционных сводных таблиц. Это имеет эффекты:
Для сводных таблиц, не соединенных с учетной записью, узлом или
пользователем, усечение сбрасывает сводные столбцы к нолю вместо того,
чтобы удалить строки. - Для сводных таблиц, соединенных с учетной записью, узлом или
пользователем, усечение удаляет строки для учетных записей, узлов или
пользователей без соединений и сбрасывает сводные столбцы к нолю
для остающихся строк.
Правила агрегирования транзакций
Операционный сбор событий происходит без отношения с уровнем изоляции,
режимом доступа или режимом autocommit.
Транзакции чтения-записи вообще требуют больше ресурсов,
чем транзакции только для чтения, поэтому операционные сводные таблицы
включают отдельные совокупные столбцы для чтения-записи
и транзакции только для чтения.
Требования ресурса могут также меняться в зависимости от операционного
уровня изоляции. Однако, предполагая, что только один уровень изоляции
использовался бы на сервере, агрегирование уровнем изоляции не обеспечено.
23.9.15.5.
Сводная таблица ожидания объектов
Performance Schema поддерживает
objects_summary_global_by_type
для того, чтобы соединить события ожидания объектов.
Резюме событий в качестве примера:
mysql> SELECT * FROM objects_summary_global_by_type\G
...
*************************** 3. row ***************************
OBJECT_TYPE: TABLE
OBJECT_SCHEMA: test
OBJECT_NAME: t
COUNT_STAR: 3
SUM_TIMER_WAIT: 263126976
MIN_TIMER_WAIT: 1522272
AVG_TIMER_WAIT: 87708678
MAX_TIMER_WAIT: 258428280
...
*************************** 10. row ***************************
OBJECT_TYPE: TABLE
OBJECT_SCHEMA: mysql
OBJECT_NAME: user
COUNT_STAR: 14
SUM_TIMER_WAIT: 365567592
MIN_TIMER_WAIT: 1141704
AVG_TIMER_WAIT: 26111769
MAX_TIMER_WAIT: 334783032
...
У
objects_summary_global_by_type
есть эти столбцы группировки, чтобы указать как табличные события
объединены: OBJECT_TYPE, OBJECT_SCHEMA и
OBJECT_NAME. Каждая строка суммирует события
для данного объекта.
objects_summary_global_by_type
имеет те же самые сводные столбцы, как
events_waits_summary_by_xxx. См.
раздел 23.9.15.1.
У
objects_summary_global_by_type есть эти индексы:
TRUNCATE TABLE позволен
для сводной таблицы объекта. Это сбрасывает сводные столбцы к нолю вместо
того, чтобы удалить строки.
23.9.15.6.
Сводные таблицы ввода/вывода файла
Performance Schema поддерживает сводные таблицы ввода/вывода файла.
Информация о резюме событий ввода/вывода файла в качестве примера:
mysql> SELECT * FROM file_summary_by_event_name\G
...
*************************** 2. row ***************************
EVENT_NAME: wait/io/file/sql/binlog
COUNT_STAR: 31
SUM_TIMER_WAIT: 8243784888
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 265928484
MAX_TIMER_WAIT: 6490658832
...
mysql> SELECT * FROM file_summary_by_instance\G
...
*************************** 2. row ***************************
FILE_NAME: /var/mysql/share/english/errmsg.sys
EVENT_NAME: wait/io/file/sql/ERRMSG
EVENT_NAME: wait/io/file/sql/ERRMSG
OBJECT_INSTANCE_BEGIN: 4686193384
COUNT_STAR: 5
SUM_TIMER_WAIT: 13990154448
MIN_TIMER_WAIT: 26349624
AVG_TIMER_WAIT: 2798030607
MAX_TIMER_WAIT: 8150662536
...
У каждой сводной таблицы ввода/вывода файла есть один или более
группирующихся столбцов, чтобы указать как табличные события объединяются.
Имена событий обращаются к названиям инструментов событий в
setup_instruments
.
У каждой сводной таблицы ввода/вывода файла есть следующие сводные
столбцы, содержащие соединенные значения. Некоторые столбцы являются более
общими и имеют значения, которые являются тем же самым, как сумма более
узконаправленных столбцов. Таким образом, данные в более высоких уровнях
доступны непосредственно без потребности в определяемых пользователем
представлениях, которые суммируют столбцы низшего уровня.
COUNT_STAR, SUM_TIMER_WAIT,
MIN_TIMER_WAIT, AVG_TIMER_WAIT,
MAX_TIMER_WAIT.
Эти столбцы агрегируют все операции ввода/вывода. COUNT_READ, SUM_TIMER_READ,
MIN_TIMER_READ, AVG_TIMER_READ,
MAX_TIMER_READ, SUM_NUMBER_OF_BYTES_READ.
Эти столбцы агрегируют все операции чтения, включая
FGETS, FGETC,
FREAD и READ. COUNT_WRITE, SUM_TIMER_WRITE,
MIN_TIMER_WRITE, AVG_TIMER_WRITE,
MAX_TIMER_WRITE, SUM_NUMBER_OF_BYTES_WRITE
Эти столбцы агрегируют все операции записи, включая
FPUTS, FPUTC,
FPRINTF, VFPRINTF,
FWRITE и PWRITE. COUNT_MISC, SUM_TIMER_MISC,
MIN_TIMER_MISC, AVG_TIMER_MISC,
MAX_TIMER_MISC
Эти столбцы агрегируют все другие операции ввода/вывода, включая
CREATE, DELETE, OPEN,
CLOSE, STREAM_OPEN, STREAM_CLOSE,
SEEK, TELL, FLUSH, STAT,
FSTAT, CHSIZE, RENAME и
SYNC. Нет никаких счетчиков байтов для этих операций.
Сводные таблицы ввода/вывода файла имеют индексы:
TRUNCATE TABLE позволен
для сводных таблиц ввода/вывода файла. Это сбрасывает сводные столбцы к
нолю вместо того, чтобы удалить строки.
Сервер MySQL использует несколько методов, чтобы избежать операций
ввода/вывода, кэшируя информацию, считанную из файлов, таким образом,
возможно, что запросов, которых Вы могли бы ожидать, не будет. Вы можете
быть в состоянии гарантировать, что ввод/вывод действительно происходит,
сбрасывая кэши или перезапуская сервер, чтобы сбросить его состояние.
23.9.15.7.
Сводные таблицы ввода/вывода и ожидания блокировки
Следующие разделы описывают табличный ввод/вывод и ожидание блокировки:
23.9.15.7.1.
Таблица table_io_waits_summary_by_table
table_io_waits_summary_by_table
собирает весь табличный ввод/вывод, произведенный инструментом
wait/io/table/sql/handler. Группировка таблицей.
table_io_waits_summary_by_table
имеет эти столбцы группировки, чтобы указать как табличные события
объединены: OBJECT_TYPE, OBJECT_SCHEMA и
OBJECT_NAME. У этих столбцов есть то же самое значение, как в
events_waits_current
. Они идентифицируют таблицу, к которой применяется строка.
table_io_waits_summary_by_table
имеет следующие сводные столбцы, содержащие соединенные значения. Как
обозначено в описаниях столбца, некоторые столбцы являются более общими и
имеют значения, которые являются тем же самым как сумма значений более
детальных столбцов. Например, столбцы, которые собирают все записи, содержат
сумму соответствующих столбцов, которые собирают вставки, обновления и
удаления. Таким образом, данные в более высоких уровнях доступны
непосредственно без потребности в определяемых пользователем представлениях,
которые суммируют столбцы низшего уровня.
COUNT_STAR, SUM_TIMER_WAIT,
MIN_TIMER_WAIT, AVG_TIMER_WAIT,
MAX_TIMER_WAIT.
Эти столбцы собирают все операции ввода/вывода. Они то же самое, как сумма
столбцов xxx_READxxx_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_INSERTxxx_UPDATExxx_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 есть эти индексы:
TRUNCATE TABLE разрешен
для табличных сводных таблиц ввода/вывода. Это сбрасывает сводные столбцы к
нолю вместо того, чтобы удалить строки. Усечение этой таблицы также усекает
table_io_waits_summary_by_index_usage.
23.9.15.7.2.
Таблица table_io_waits_summary_by_index_usage
table_io_waits_summary_by_index_usage собирает все события
ожидания ввода/вывода индексов как произведено инструментом
wait/io/table/sql/handler. Группировка по индексу таблицы.
Столбцы
table_io_waits_summary_by_index_usage почти идентичны
table_io_waits_summary_by_table. Единственная разница:
дополнительный групповой столбец INDEX_NAME,
который соответствует названию индекса, который использовался,
когда случай ожидания табличного ввода/вывода был зарегистрирован:
У
table_io_waits_summary_by_index_usage есть эти индексы:
TRUNCATE TABLE
разрешен для сводных таблиц ввода/вывода. Это сбрасывает сводные столбцы к
нолю вместо того, чтобы удалить строки. Эта таблица является также усеченной
усечением
table_io_waits_summary_by_table. Операция DDL, которая
изменяет индексную структуру таблицы, может вызвать
сброс статистики индексов.
23.9.15.7.3.
Таблица table_lock_waits_summary_by_table
table_lock_waits_summary_by_table собирает все события ожидания
табличной блокировки как произведено инструментом
wait/lock/table/sql/handler. Группировка по таблице.
Эта таблица содержит информацию о внутренних и внешних блокировках:
Внутренняя блокировка соответствует блокировке в уровне 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_READxxx_WRITE COUNT_READ, SUM_TIMER_READ,
MIN_TIMER_READ, AVG_TIMER_READ,
MAX_TIMER_READ
Эти столбцы агрегируют все операции блокировки чтения. Они то же самое,
как сумма соответствующих столбцов xxx
_READ_NORMALxxx_READ_WITH_SHARED_LOCKS
xxx_READ_HIGH_PRIORITYxxx_READ_NO_INSERT COUNT_WRITE, SUM_TIMER_WRITE,
MIN_TIMER_WRITE, AVG_TIMER_WRITE,
MAX_TIMER_WRITE
Эти столбцы агрегируют все операции блокировки записи. Они то же самое,
как сумма соответствующих столбцов
xxx_WRITE_ALLOW_WRITExxx_WRITE_CONCURRENT_INSERTxxx_WRITE_LOW_PRIORITYxxx_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 есть эти индексы:
TRUNCATE TABLE
разрешен для сводных таблиц блокировки. Это сбрасывает сводные столбцы к нолю
вместо того, чтобы удалить строки.
23.9.15.8. Сводные таблицы сокета
Эти сводные таблицы сокета агрегируют информацию таймера и число байт
для операций сокета:
Сводные таблицы сокета не соединяют ожидания, произведенные событиями
idle в то время, как сокеты ждут следующего запроса от клиента.
Для агрегирования событий idle, используйте сводные таблицы
случаев ожидания, см.
раздел 23.9.15.1.
У каждой сводной таблицы сокета есть один или более группирующихся
столбцов, чтобы указать как табличные события объединены.
Имена событий обращаются к названиям инструментов событий в
setup_instruments
.
У каждой сводной таблицы сокета есть эти сводные столбцы,
содержащие соединенные значения:
COUNT_STAR, SUM_TIMER_WAIT,
MIN_TIMER_WAIT, AVG_TIMER_WAIT,
MAX_TIMER_WAIT
Эти столбцы агрегируют все операции. COUNT_READ, SUM_TIMER_READ,
MIN_TIMER_READ, AVG_TIMER_READ,
MAX_TIMER_READ, SUM_NUMBER_OF_BYTES_READ
Эти столбцы агрегируют все операции получения
(RECV, RECVFROM и RECVMSG). COUNT_WRITE, SUM_TIMER_WRITE,
MIN_TIMER_WRITE, AVG_TIMER_WRITE,
MAX_TIMER_WRITE, SUM_NUMBER_OF_BYTES_WRITE
Эти столбцы агрегируют все операции передачи
(SEND, SENDTO и SENDMSG). COUNT_MISC, SUM_TIMER_MISC,
MIN_TIMER_MISC, AVG_TIMER_MISC,
MAX_TIMER_MISC
Эти столбцы агрегируют все прочие операции, такие как
CONNECT, LISTEN,
ACCEPT, CLOSE и SHUTDOWN.
Нет никаких счетчиков байтов для этих операций.
socket_summary_by_instance также имеет столбец
EVENT_NAME, который указывает на класс сокета:
client_connection, server_tcpip_socket,
server_unix_socket.
Этот столбец может быть сгруппирован на изоляцию, например, деятельность
клиента, от которого сервер слушает сокеты.
Сводные таблицы сокета имеют индексы:
TRUNCATE TABLE позволен
на сводных таблицах сокета. За исключением
events_statements_summary_by_digest
это сбрасывает сводные столбцы к нолю вместо того, чтобы удалить строки.
23.9.15.9. Сводные таблицы памяти
Инструментальное использование памяти Performance Schema и
статистика использования памяти детализирована этими факторами:
Performance Schema инструментует следующие аспекты использования памяти:
Размеры памяти. - Количество работы.
- Нижняя и верхняя метки.
Размеры памяти помогают понять или настроить потребление памяти сервером.
Графы работы помогают понять или настроить полное распределение памяти,
который оказывает влияние на работу. Выделение единственного байта один
миллион раз не является тем же самым как выделение мегабайта разово,
отслеживание количества и размеров может выставить различие.
Метки важны, чтобы обнаружить пики рабочей нагрузки, полную стабильность
рабочей нагрузки и возможные утечки памяти.
Сводные таблицы памяти не содержат информацию о синхронизации, потому что
события памяти не рассчитаны.
Информация о резюме событий памяти в качестве примера:
mysql> SELECT * FROM memory_summary_global_by_event_name
WHERE EVENT_NAME = 'memory/sql/TABLE'\G
*************************** 1. row ***************************
EVENT_NAME: memory/sql/TABLE
COUNT_ALLOC: 1381
COUNT_FREE: 924
SUM_NUMBER_OF_BYTES_ALLOC: 2059873
SUM_NUMBER_OF_BYTES_FREE: 1407432
LOW_COUNT_USED: 0
CURRENT_COUNT_USED: 457
HIGH_COUNT_USED: 461
LOW_NUMBER_OF_BYTES_USED: 0
CURRENT_NUMBER_OF_BYTES_USED: 652441
HIGH_NUMBER_OF_BYTES_USED: 669269
У каждой сводной таблицы памяти есть один или более группирующихся
столбцов, чтобы указать как табличные события объединены. Имена событий
обращаются к названиям инструментов событий в
setup_instruments
.
У каждой сводной таблицы памяти есть эти сводные столбцы,
содержащие соединенные значения:
COUNT_ALLOC, COUNT_FREE
Соединенные числа вызовов функций, подобных malloc и free. SUM_NUMBER_OF_BYTES_ALLOC,
SUM_NUMBER_OF_BYTES_FREE
Соединенные размеры выделенных и освобожденных блоков памяти. CURRENT_COUNT_USED
Соединенное число в настоящее время выделяемых блоков, которые еще не были
освобождены. Это столбец удобства, равный
COUNT_ALLOC - COUNT_FREE. CURRENT_NUMBER_OF_BYTES_USED
Соединенный размер в настоящее время выделяемых блоков памяти, которые еще
не были освобождены. Это столбец удобства, равный
SUM_NUMBER_OF_BYTES_ALLOC-SUM_NUMBER_OF_BYTES_FREE.
LOW_COUNT_USED, HIGH_COUNT_USED
Метки, соответствующие столбцу CURRENT_COUNT_USED. LOW_NUMBER_OF_BYTES_USED,
HIGH_NUMBER_OF_BYTES_USED
Метки, соответствующие столбцу CURRENT_NUMBER_OF_BYTES_USED.
Сводные таблицы памяти имеют индексы:
TRUNCATE TABLE позволен
на сводных таблицах памяти. Это имеет эффекты:
Вообще, усечение сбрасывает базовую линию для статистики, но не
изменяет состояние сервера. Таким образом, усечение таблицы памяти
не освобождает память. COUNT_ALLOC и COUNT_FREE
сброшены к новой базовой линии, уменьшая каждый счетчик тем
же самым значением.- Аналогично
SUM_NUMBER_OF_BYTES_ALLOC и
SUM_NUMBER_OF_BYTES_FREE
сброшены к новой базовой линии.
LOW_COUNT_USED и HIGH_COUNT_USED
сброшены к CURRENT_COUNT_USED.LOW_NUMBER_OF_BYTES_USED и
HIGH_NUMBER_OF_BYTES_USED сброшены к
CURRENT_NUMBER_OF_BYTES_USED.
Кроме того, каждая сводная таблица памяти, которая соединена с учетной
записью, узлом, пользователем или потоком, является неявно усеченной
усечением таблицы, от которой зависит, или усечением
memory_summary_global_by_event_name. Для деталей см.
раздел 23.9.8.
Поведение инструментовки памяти
Большинство инструментов памяти отключено по умолчанию и может быть
включено или отключено динамически, обновляя столбец ENABLED
соответствующих инструментов в
setup_instruments
. У инструментов памяти есть названия формы
memory/code_area/instrument_name
.
Чтобы включить все инструменты памяти, выполните этот запрос:
mysql> UPDATE setup_instruments SET ENABLED='YES'
WHERE NAME LIKE 'memory/%';
Инструменты с приставкой memory/performance_schema/
показывают, сколько памяти выделено для внутренних буферов в
Performance Schema непосредственно. Инструменты
memory/performance_schema/ встроены, всегда включаются и не
могут быть отключены при запуске или во время выполнения. Встроенные
инструменты памяти выведены на экран только в таблице
memory_summary_global_by_event_name.
Для инструментов памяти столбец TIMED в
setup_instruments
проигнорирован, потому что операции памяти не рассчитаны.
Когда поток в сервере выполняет распределение памяти, которое было
инструментовано, эти правила применяются:
Для освобождения применяются эти правила:
Если поток инструментован, а блок памяти не инструментован,
освобождение не инструментовано, никакие статистические данные не изменены.
- Если поток не инструментован, а блок памяти инструментован,
освобождение инструментовано, статистические данные изменены.
Для статистики по потокам применяются следующие правила.
Когда инструментованный блок памяти размера
N выделен, Performance Schema
делает эти обновления столбцов сводной таблицы памяти:
Когда инструментованный блок памяти освобожден,
Performance Schema делает эти обновления столбцов сводной таблицы памяти:
Для высокоуровневых совокупностей (глобальной, учетной записи,
пользователя, узла) те же самые правила применяются.
LOW_COUNT_USED и
LOW_NUMBER_OF_BYTES_USED более низкие оценки. Значение, о
котором сообщает Performance Schema, будет меньше чем или равно самому
низкому размеру памяти, эффективно используемой во время выполнения.
HIGH_COUNT_USED и
HIGH_NUMBER_OF_BYTES_USED
более высокие оценки. Значение, о котором сообщает Performance Schema,
будет больше чем или равным самому высокому размеру памяти, эффективно
используемой во время выполнения.
Для более низких оценок в сводных таблицах кроме
memory_summary_global_by_event_name,
возможны отрицательные значения, если память передана между потоками.
Вот пример оценочного вычисления,
отметьте, что оценочное выполнение подвержено изменениям:
Поток 1 использует память в диапазоне от 1 МБ до 2 МБ во время выполнения,
как сообщают столбцы LOW_NUMBER_OF_BYTES_USED и
HIGH_NUMBER_OF_BYTES_USED в
memory_summary_by_thread_by_event_name.
Поток 2 использует память в диапазоне от 10 МБ до 12 МБ
во время выполнения.
Когда эти два потока принадлежат той же самой учетной записи пользователя,
резюме на учетную запись оценивает, что эта учетная запись использовала
память в диапазоне от 11 МБ до 14 МБ. Таким образом,
LOW_NUMBER_OF_BYTES_USED как высокоуровневая совокупность это
сумма всех LOW_NUMBER_OF_BYTES_USED (принятие худшего случая).
Аналогично HIGH_NUMBER_OF_BYTES_USED как
высокоуровневая совокупность это сумма всех
HIGH_NUMBER_OF_BYTES_USED (принятие худшего случая).
11MB более низкая оценка, которая может произойти, только если оба потока
в то же самое время проходят низкую метку использования.
14MB более высокая оценка, которая может произойти, только если оба потока
в то же самое время проходят высокую метку использования.
Реальное использование памяти для этой учетной записи, возможно, было в
диапазоне от 11.5MB до 13.5MB.
Для планирования мощностей, сообщение о худшем случае фактически желаемое
поведение, поскольку это показывает то, что может потенциально произойти,
когда сеансы являются некоррелироваными, что, как правило, имеет место.
23.9.15.10. Сводные таблицы ошибок
Performance Schema поддерживает сводные таблицы для того, чтобы соединить
статистическую информацию об ошибках и предупреждениях сервера. Для списка
ошибок сервера см. раздел B.3.
Сбором информации об ошибке управляет инструмент error,
который включен по умолчанию. Информация синхронизации не собрана.
У каждой сводной таблицы есть три столбца, которые идентифицируют ошибку:
Например, если ERROR_NUMBER 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
У каждой сводной таблицы есть один или более группирующихся столбцов,
чтобы указать как табличные ошибки объединяются:
У каждой сводной таблицы есть эти сводные столбцы,
содержащие соединенные значения:
SUM_ERROR_RAISED
Этот столбец показывает, сколько раз ошибка произошла. SUM_ERROR_HANDLED
Этот столбец показывает, сколько раз
ошибка была обработана обработчиком исключения SQL. FIRST_SEEN, LAST_SEEN
Timestamp, указывающий, когда ошибка была замечена в
первый и в последний раз.
Строка NULL в каждой сводной таблице нужна для
совокупной статистики для всех ошибок, которые лежат вне диапазона
инструментованных ошибок. Например, если ошибки MySQL Server
находятся в диапазоне от M до
N и ошибка поднята с номером
Q не в этом диапазоне, ошибка показана в строке
NULL. Это строка с ERROR_NUMBER=0,
ERROR_NAME=NULL и SQLSTATE=NULL.
Сводные таблицы ошибок имеют индексы:
TRUNCATE TABLE позволен
на сводных таблицах ошибок. Это имеет эффекты:
Для сводных таблиц, не соединенных учетной записью, узлом или
пользователем, усечение сбрасывает сводные столбцы к нолю или
NULL вместо того, чтобы удалять строки. - Для сводных таблиц, соединенных учетной записью, узлом или пользователем,
усечение удаляет строки для учетных записей, узлов или пользователей без
соединений и сбрасывает сводные столбцы к нолю или
NULL
для остающихся строк.
Кроме того, каждая сводная таблица, которая соединена учетной записью,
узлом, пользователем или потоком, является неявно усеченной усечением таблицы
соединения, от которой зависит, или усечением
events_errors_summary_global_by_error. Детали в
разделе 23.9.8.
23.9.15.11. Сводные таблицы переменных состояния
Значение системной переменной
show_compatibility_56 затрагивает информацию, доступную из
таблиц, описанных здесь. Для деталей см. описание этой переменной в
разделе 6.1.5.
Performance Schema делает доступной информацию о переменных
состояния в таблицах, описанных в
разделе
23.9.14. Это также делает соединенную информацию о переменной состояния
доступной в сводных таблицах, описанных здесь. У каждой сводной таблицы
переменной состояния есть один или более группирующихся столбцов, чтобы
указать, как таблица агрегирует переменные:
У каждой сводной таблицы переменных состояния есть этот сводный столбец,
содержащий соединенные значения:
Сводные таблицы переменной состояния имеют индексы:
Смысл account в этих таблицах подобно его значению в таблицах
привилегий MySQL системной базы данных mysql,
в том смысле, что термин относится к комбинации значений узла и пользователя.
Они отличаются тем, что для таблиц привилегий часть узла учетной записи может
быть образцом, тогда как для Performance Schema значение узла всегда
определенное имя хоста.
Состояние учетной записи собрано, когда сеансы заканчиваются.
Счетчики состояния сеанса добавлены к глобальным счетчикам состояния и
соответствующим счетчикам состояния учетной записи. Если статистические
данные учетной записи не собраны, состояние сеанса добавлено к состояниям
хоста и пользователя, если узел и пользовательское состояние собираются.
Учетная запись, узел и пользовательская статистика не собраны, если
переменные
performance_schema_accounts_size,
performance_schema_hosts_size и
performance_schema_users_size, соответственно, установлены в 0.
Performance Schema поддерживает
TRUNCATE TABLE для сводных таблиц переменных состояния следующим
образом, во всех случаях состояние для активных сеансов не затронуто:
FLUSH STATUS
добавляет состояние сеанса от всех активных сеансов к глобальным переменным
состояния, сбрасывает состояние всех активных сеансов и сбрасывает учетную
запись, узел и пользовательские значения состояния от разъединенных сеансов.
23.9.16.
Прочие таблицы Performance Schema
Следующие разделы описывают таблицы, которые не попадают в табличные
категории, обсужденные в предыдущих разделах:
23.9.16.1. Таблица host_cache
Таблица host_cache
обеспечивает доступ к содержанию кэша узла, который содержит имя хоста
клиента и информацию об IP-адресе и используется, чтобы избежать поисков DNS
(см. раздел 9.12.4.2).
host_cache
выставляет содержание кэша узла так, чтобы это могло быть исследовано,
используя SELECT. Performance
Schema должна быть включена, или эта таблица пуста.
У host_cache
есть эти столбцы:
IP
IP-адрес клиента, который соединялся с сервером, выраженный как строка.
HOST
Имя хоста DNS для IP клиента или NULL,
если имя неизвестно. HOST_VALIDATED
Было ли разрешение DNS "имя к IP" или "IP к узлу" выполнено успешно для
IP клиента. Если HOST_VALIDATED = YES,
HOST используется в качестве имени хоста, соответствующего IP
так, чтобы вызовов DNS можно было избежать. В то время, как
HOST_VALIDATED = NO, разрешение DNS
предпринято снова для каждого соединения, пока оно в конечном счете не
завершается с допустимым результатом или с постоянной ошибкой.
Эта информация позволяет серверу избежать плохого кэширования или пропуска
имени хоста во время временных отказов DNS, которые затронули
бы клиентов навсегда. SUM_CONNECT_ERRORS
Число ошибок соединения, которые считаются
blocking (оценены относительно переменной
max_connect_errors
). Только ошибки квитирования протокола посчитаны и только для
узлов, которые передали проверку допустимости
(HOST_VALIDATED = YES). COUNT_HOST_BLOCKED_ERRORS
Число соединений, которые были заблокированы потому, что
SUM_CONNECT_ERRORS превышает значение переменной
of the
max_connect_errors. COUNT_NAMEINFO_TRANSIENT_ERRORS
Число переходных ошибок во время разрешения DNS IP к имени хоста. COUNT_NAMEINFO_PERMANENT_ERRORS
Число постоянных ошибок во время разрешения DNS IP к имени хоста. COUNT_FORMAT_ERRORS
Число ошибок формата имени хоста. MySQL не выполняет соответствие
значения столбцов Host в mysql.user
именам хоста, для которых один или больше начальных компонентов имени
являются полностью числовыми (1.2.example.com).
IP-адрес клиента используется вместо этого. Для объяснения, почему этот тип
соответствия не происходит, см. раздел
7.2.3. COUNT_ADDRINFO_TRANSIENT_ERRORS
Число переходных ошибок во время разрешения DNS имени хоста к IP. COUNT_ADDRINFO_PERMANENT_ERRORS
Число постоянных ошибок во время разрешения DNS имени хоста к IP. COUNT_FCRDNS_ERRORS
Число передовых подтвержденных обратных ошибок DNS. Эти ошибки
происходят, когда разрешение DNS производит IP-адрес, который не
соответствует клиенту, порождающему IP-адрес. COUNT_HOST_ACL_ERRORS
Число ошибок, которые происходят, потому что никакой пользователь с хоста
клиента не может возможно войти в систему. В таких случаях сервер
возвращает
ER_HOST_NOT_PRIVILEGED и даже не просит имя
пользователя или пароль. COUNT_NO_AUTH_PLUGIN_ERRORS
Число ошибок из-за запросов о недоступном плагине аутентификации. Плагин
может быть недоступным, если, например, он никогда не загружался, или
попытка загрузки провалилась. COUNT_AUTH_PLUGIN_ERRORS
Число ошибок, сообщенных плагинами аутентификации.
Плагин аутентификации может сообщить, различные коды ошибки, которые
указывают на первопричину отказа. В зависимости от типа ошибки увеличен один
из этих столбцов: COUNT_AUTHENTICATION_ERRORS,
COUNT_AUTH_PLUGIN_ERRORS,
COUNT_HANDSHAKE_ERRORS. Новые коды возвращения это
дополнительное расширение к существующему API. Неизвестные или неожиданные
ошибки включены в столбец COUNT_AUTH_PLUGIN_ERRORS. COUNT_HANDSHAKE_ERRORS
Число ошибок обнаружено на проводном уровне протокола. COUNT_PROXY_USER_ERRORS
Число ошибок обнаружило, когда proxy-пользователь A передает доступ
другому пользователю B, который не существует. COUNT_PROXY_USER_ACL_ERRORS
Число ошибок, когда proxy-пользователь A передает доступ другому
пользователю B, который действительно существует, но для кого A не имеет
привилегии PROXY. COUNT_AUTHENTICATION_ERRORS
Число ошибок вызвано неудавшейся аутентификацией. COUNT_SSL_ERRORS
Число ошибок из-за проблем SSL. COUNT_MAX_USER_CONNECTIONS_ERRORS
Число ошибок вызвано превышением доли соединения в расчёте на
пользователя. См. раздел 7.3.5.
COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS
Число ошибок вызвано, превышая доли соединений-за-час
в расчёте на пользователя. См.
раздел 7.3.5. COUNT_DEFAULT_DATABASE_ERRORS
Число ошибок, связанных с базой данных по умолчанию. Например, база данных
не существовала, или у пользователя не было никаких привилегий для того,
чтобы получить доступ к ней. COUNT_INIT_CONNECT_ERRORS
Число ошибок, вызванных отказами выполнения запросов в
init_connect. COUNT_LOCAL_ERRORS
Число ошибок, локальных к выполнению сервера и не связанных с сетью,
аутентификацией или разрешением. Например, условия переполнения памяти
попадают в эту категорию. COUNT_UNKNOWN_ERRORS
Число других, неизвестных ошибок, не составляемых другими столбцами в этой
таблице. Этот столбец сохранен для будущего использования, в случае, если о
новых состояниях ошибки нужно сообщить, сохраняя обратную совместимость и
структуру таблицы host_cache
. FIRST_SEEN
timestamp первой попытки соединения, замеченной
от клиента в IP. LAST_SEEN
timestamp последней попытки соединения, замеченной
от клиента в IP. FIRST_ERROR_SEEN
timestamp первой ошибки, замеченной от клиента в IP. LAST_ERROR_SEEN
timestamp последней ошибки, замеченной от клиента в IP.
У host_cache
есть эти индексы:
Первичный ключ на (IP). - Индекс на (
HOST).
FLUSH HOSTS и
TRUNCATE TABLE host_cache
имеют тот же самый эффект: они очищают кэш узла. Это также удаляет строки из
host_cache
(потому что это видимое представление кэша) и открывает любые заблокированные
узлы (см. раздел B.5.2.5).
FLUSH HOSTS требует привилегии
RELOAD.
TRUNCATE TABLE требует
привилегии DROP для
host_cache.
23.9.16.2.
Таблица performance_timers
performance_timers
показывает, какие таймеры событий доступны:
mysql> SELECT * FROM performance_timers;
+-------------+-----------------+------------------+----------------+
| TIMER_NAME | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+-------------+-----------------+------------------+----------------+
| CYCLE | 2389029850 | 1 | 72 |
| NANOSECOND | 1000000000 | 1 | 112 |
| MICROSECOND | 1000000 | 1 | 136 |
| MILLISECOND | 1036 | 1 | 168 |
| TICK | 105 | 1 | 2416 |
+-------------+-----------------+------------------+----------------+
Таймеры в setup_timers
, которые Вы можете использовать, не имеют NULL
в других столбцах. Если значения, связанные с данным именем таймера,
NULL, этот таймер не поддержан на Вашей платформе.
У performance_timers
есть эти столбцы:
TIMER_NAME
Имя, которым можно обратиться к таймеру, конфигурируя
setup_timers. TIMER_FREQUENCY
Число модулей таймера в секунду. Для счетчика циклов частота вообще
связана со скоростью центрального процессора. Например, на системе с 2.4GHz
процессором CYCLE может быть близко к 2400000000. TIMER_RESOLUTION
Указывает на число модулей таймера, которыми таймер оценивает увеличение.
Если у таймера есть разрешение 10, его значение увеличено на 10 каждый раз.
TIMER_OVERHEAD
Минимальное число циклов, чтобы получить одну синхронизацию с данным
таймером. Performance Schema определяет это значение, вызывая таймер 20 раз
во время инициализации и выбирая самое маленькое значение. Общее количество
циклов дважды это количество, потому что инструментовка вызывает таймер в
запуске и конце каждого случая. Код таймера называют только для рассчитанных
событий, таким образом, это не влияет на нерассчитанные события.
TRUNCATE TABLE не
позволен для
performance_timers.
23.9.16.3. Таблица threads
Таблица threads
содержит строку для каждого потока сервера. Каждая строка содержит информацию
о потоке и указывает, включен ли контроль и журналирование событий:
mysql> SELECT * FROM threads\G
*************************** 1. row ***************************
THREAD_ID: 1
NAME: thread/sql/main
TYPE: BACKGROUND
PROCESSLIST_ID: NULL
PROCESSLIST_USER: NULL
PROCESSLIST_HOST: NULL
PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: NULL
PROCESSLIST_TIME: 80284
PROCESSLIST_STATE: NULL
PROCESSLIST_INFO: NULL
PARENT_THREAD_ID: NULL
ROLE: NULL
INSTRUMENTED: YES
HISTORY: YES
CONNECTION_TYPE: NULL
THREAD_OS_ID: 489803
...
*************************** 4. row ***************************
THREAD_ID: 51
NAME: thread/sql/one_connection
TYPE: FOREGROUND
PROCESSLIST_ID: 34
PROCESSLIST_USER: isabella
PROCESSLIST_HOST: localhost
PROCESSLIST_DB: performance_schema
PROCESSLIST_COMMAND: Query
PROCESSLIST_TIME: 0
PROCESSLIST_STATE: Sending data
PROCESSLIST_INFO: SELECT * FROM threads
PARENT_THREAD_ID: 1
ROLE: NULL
INSTRUMENTED: YES
HISTORY: YES
CONNECTION_TYPE: SSL/TLS
THREAD_OS_ID: 755399
...
Когда Performance Schema инициализируется, она заполняет
threads, основываясь на
существующих потоках. После этого новая строка добавлена каждый раз, когда
сервер создает поток.
Столбцы INSTRUMENTED и HISTORY
для новых потоков определены содержанием
setup_actors.
Для информации о том, как использовать
setup_actors, чтобы
управлять этими столбцами, см.
раздел 23.2.3.6.
Удаление строк из threads
происходит, когда потоки заканчиваются. Для потока, связанного с сеансом
клиента, происходит удаление, когда сеанс заканчивается. Если клиент имеет
включенную опцию auto-reconnect, и сеанс повторно соединяется после
разъединения, то этот сеанс становится связанным с новой строкой в
threads, у которой есть
другой PROCESSLIST_ID. Значения INSTRUMENTED и
HISTORY для нового потока
могут отличаться от таковых из оригинального потока:
setup_actors,
возможно, изменилась тем временем, и если
INSTRUMENTED или HISTORY
для оригинального потока было изменено после того, как строка была
инициализирована, изменение не переносится на новый поток.
Столбцы таблицы threads
с именами, имеющими приставку PROCESSLIST_,
предоставляют информацию, подобную доступной из
INFORMATION_SCHEMA.PROCESSLIST
или SHOW PROCESSLIST
. Таким образом, все три источника предоставляют контролирующую
поток информацию. Использование
threads
отличается от использования других двух источников:
По этим причинам, DBA выполняет контроль сервера, используя
INFORMATION_SCHEMA.PROCESSLIST
или SHOW PROCESSLIST
и может хотеть контролировать, используя вместо этого
threads.
Для
INFORMATION_SCHEMA.PROCESSLIST
и SHOW PROCESSLIST
информацию о потоках для других пользователей показывают, только если текущий
пользователь имеет привилегию
PROCESS.
Это не так для таблицы threads
: все строки показывают любому пользователю, который имеет
привилегию SELECT для таблицы. Пользователям, которые не должны
быть в состоянии видеть потоки для других пользователей, нельзя
давать эту привилегию.
У threads
есть эти столбцы:
THREAD_ID
Уникальный идентификатор потока. NAME
Имя, связанное с кодом инструментовки потока в сервере. Например,
thread/sql/one_connection соответствует функции потока в коде,
ответственном за обработку пользовательского соединения, а
thread/sql/main для функции main() сервера. TYPE
Тип потока: FOREGROUND или BACKGROUND.
Пользовательские потоки соединения это потоки переднего плана. Потоки,
связанные с внутренней деятельностью сервера, являются фоновыми потоками.
PROCESSLIST_ID
Для потоков, которые выведены на экран в
INFORMATION_SCHEMA.PROCESSLIST
это значение столбца ID этой таблицы.
Это также значение, выведенное на экран в столбце Id вывода
SHOW PROCESSLIST и
значение, возвращаемое функцией
CONNECTION_ID() для потока.
Для фоновых потоков (потоки, не связанные с пользовательским соединением),
PROCESSLIST_ID NULL,
таким образом, значения не уникальны. PROCESSLIST_USER
Пользователь, связанный с потоком переднего плана, NULL
для фонового потока. PROCESSLIST_HOST
Имя хоста клиента, связанного с потоком переднего плана,
NULL для фонового потока.
В отличие от столбца HOST в INFORMATION_SCHEMA,
PROCESSLIST или
столбец Host вывода
SHOW PROCESSLIST,
столбец PROCESSLIST_HOST не включает номер порта для соединений
TCP/IP. Чтобы получить эту информацию из Performance Schema,
включите инструментовку сокета (которая не включена по умолчанию) и
исследуйте таблицу
socket_instances:
mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'wait/io/socket%';
+----------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+----------------------------------------+---------+-------+
| wait/io/socket/sql/server_tcpip_socket | NO | NO |
| wait/io/socket/sql/server_unix_socket | NO | NO |
| wait/io/socket/sql/client_connection | NO | NO |
+----------------------------------------+---------+-------+
3 rows in set (0.01 sec)
mysql> UPDATE setup_instruments SET ENABLED='YES'
WHERE NAME LIKE 'wait/io/socket%';
Query OK, 3 rows affected (0.00 sec)
Rows matched: 3 Changed: 3 Warnings: 0
mysql> SELECT * FROM socket_instances\G
*************************** 1. row ***************************
EVENT_NAME: wait/io/socket/sql/client_connection
OBJECT_INSTANCE_BEGIN: 140612577298432
THREAD_ID: 31
SOCKET_ID: 53
IP: ::ffff:127.0.0.1
PORT: 55642
STATE: ACTIVE
...
PROCESSLIST_DB
База данных значения по умолчанию для потока или
NULL, если нет. PROCESSLIST_COMMAND
Для потоков переднего плана команда выполняется от имени клиента или
Sleep, если сессия спит. Для описаний команд потока см.
раздел 9.14.
Значение этого столбца соответствует командам
COM_xxx протокола клиент-сервер и
переменным состояния Com_xxx. См.
раздел 6.1.7.
Фоновые потоки не выполняют команды от имени клиентов, таким образом,
этот столбец может быть NULL. PROCESSLIST_TIME
Время в секундах, которое поток был в его текущем состоянии. PROCESSLIST_STATE
Действие, случай или состояние, которое указывает на то, что делает поток.
Для описания значений PROCESSLIST_STATE см.
раздел 9.14. Если значение
NULL, поток может соответствовать неактивному сеансу клиента,
или работа, которую он делает, не инструментована с этапами.
Большинство состояний соответствует очень быстрым операциям. Если поток
остается в данном статусе в течение многих секунд, может быть проблема. PROCESSLIST_INFO
Запрос, который поток выполняет, или NULL,
если это не выполняет запросы. Запрос мог быть послан в сервер или внутренним
запросом, если запрос выполняет другие запросы. Например, если
CALL выполняет хранимую процедуру, которая выполняет
SELECT, значение
PROCESSLIST_INFO показывает запрос
SELECT. PARENT_THREAD_ID
Если этот поток подпоток (порожденный другим потоком), это
THREAD_ID основного потока. ROLE
Не используется. INSTRUMENTED
Инструментованы ли события, запущенные потоком.
Значения YES или NO.
Для потоков переднего плана, начальное значение
INSTRUMENTED определено тем, соответствует ли учетная запись
пользователя, связанная с потоком, какой-либо строке в
setup_actors.
Соответствие основано на значениях
PROCESSLIST_USER и PROCESSLIST_HOST.
Если поток порождает подпоток, соответствие происходит снова для
строки таблицы threads,
созданной для подпотока. - Для фоновых потоков
INSTRUMENTED YES
по умолчанию. setup_actors
не консультируется, потому что нет никакого связанного
пользователя для фоновых потоков.
- Для любого потока значение
INSTRUMENTED
может быть изменено во время жизни потока.
Для того, чтобы контролировать события, запущенные потоком, эти вещи
должны быть истиной:
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
Поток или идентификатор задачи как определено основной операционной
системой, если есть:
Для 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
есть эти индексы:
TRUNCATE TABLE не
позволен для threads.
23.10.
Обзор опций и переменных Performance Schema
Таблица 23.3. Обзор переменных Performance Schema
23.11.
Опции команд Performance Schema
Параметры Performance Schema могут быть определены при запуске сервера в
командной строке или в файлах опции, чтобы сконфигурировать инструменты и
потребителей Performance Schema. Конфигурация во время выполнения также
возможна во многих случаях (см.
раздел 23.2.3
), но конфигурация запуска должна использоваться, когда конфигурация во
время выполнения должна слишком поздно затронуть инструменты,
которые были уже инициализированы во время процесса запуска.
Потребители и инструменты Performance Schema
могут быть сконфигурированы при запуске, используя следующий синтаксис.
Для дополнительных деталей см.
раздел 23.2.2
.
Следующие элементы конфигурируют отдельных потребителей:
23.12.
Системные переменные Performance Schema
осуществляет несколько системных переменных, которые
предоставляют информацию о конфигурации:
mysql> SHOW VARIABLES LIKE 'perf%';
+----------------------------------------------------------+-------+
| Variable_name | Value |
+----------------------------------------------------------+-------+
| performance_schema | ON |
| performance_schema_accounts_size | -1 |
| performance_schema_digests_size | 10000 |
| performance_schema_events_stages_history_long_size | 10000 |
| performance_schema_events_stages_history_size | 10 |
| performance_schema_events_statements_history_long_size | 10000 |
| performance_schema_events_statements_history_size | 10 |
| performance_schema_events_transactions_history_long_size | 10000 |
| performance_schema_events_transactions_history_size | 10 |
| performance_schema_events_waits_history_long_size | 10000 |
| performance_schema_events_waits_history_size | 10 |
| performance_schema_hosts_size | -1 |
| performance_schema_max_cond_classes | 80 |
| performance_schema_max_cond_instances | -1 |
| performance_schema_max_digest_length | 1024 |
| performance_schema_max_file_classes | 50 |
| performance_schema_max_file_handles | 32768 |
| performance_schema_max_file_instances | -1 |
| performance_schema_max_index_stat | -1 |
| performance_schema_max_memory_classes | 320 |
| performance_schema_max_metadata_locks | -1 |
| performance_schema_max_mutex_classes | 200 |
| performance_schema_max_mutex_instances | -1 |
| performance_schema_max_prepared_statements_instances | -1 |
| performance_schema_max_program_instances | -1 |
| performance_schema_max_rwlock_classes | 40 |
| performance_schema_max_rwlock_instances | -1 |
| performance_schema_max_socket_classes | 10 |
| performance_schema_max_socket_instances | -1 |
| performance_schema_max_sql_text_length | 1024 |
| performance_schema_max_stage_classes | 150 |
| performance_schema_max_statement_classes | 192 |
| performance_schema_max_statement_stack | 10 |
| performance_schema_max_table_handles | -1 |
| performance_schema_max_table_instances | -1 |
| performance_schema_max_table_lock_stat | -1 |
| performance_schema_max_thread_classes | 50 |
| performance_schema_max_thread_instances | -1 |
| performance_schema_session_connect_attrs_size | 512 |
| performance_schema_setup_actors_size | -1 |
| performance_schema_setup_objects_size | -1 |
| performance_schema_users_size | -1 |
+----------------------------------------------------------+-------+
Системные переменные Performance Schema могут быть установлены при запуске
сервера в командной строке или в файлах опции, и многие могут быть
установлены во времени выполнения. См.
раздел
23.10.
Performance Schema автоматически измеряет значения нескольких из ее
параметров при запуске сервера, если они не установлены явно.
Для получения дополнительной информации см.
раздел 23.2.2
.
У системных переменных Performance Schema есть следующие значения:
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
Число строк в
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
Число строк в
events_transactions_history_long.
-
performance_schema_events_transactions_history_size
| Формат командной строки
|
--performance_schema_events_transactions_history_size=# |
| Системная |
Имя |
performance_schema_events_transactions_history_size |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autosized) |
Число строк на поток в
events_transactions_history.
-
performance_schema_events_waits_history_long_size
| Формат командной строки
|
--performance_schema_events_waits_history_long_size=# |
| Системная |
Имя |
performance_schema_events_waits_history_long_size |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autosized) |
Число строк в
events_waits_history_long.
-
performance_schema_events_waits_history_size
| Формат командной строки
|
--performance_schema_events_waits_history_size=# |
| Системная |
Имя |
performance_schema_events_waits_history_size |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autosized) |
Число строк на поток в
events_waits_history
.
-
performance_schema_hosts_size
| Формат командной строки
| --performance_schema_hosts_size=#
|
| Системная |
Имя |
performance_schema_hosts_size |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autoscaled) |
| Минимум |
-1 (autoscaled) |
| Максимум |
1048576 |
Число строк в hosts.
Если эта переменная 0, Performance Schema не поддерживает статистику
соединения в hosts
или информацию о переменных состояния в
status_by_host.
-
performance_schema_max_cond_classes
| Формат командной строки
| --performance_schema_max_cond_classes=#
|
| Системная |
Имя |
performance_schema_max_cond_classes |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
80 |
Максимальное количество инструментованных условий.
-
performance_schema_max_cond_instances
| Формат командной строки
| --performance_schema_max_cond_instances=#
|
| Системная |
Имя |
performance_schema_max_cond_instances |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autoscaled) |
Максимальное количество инструментованных объектов условия.
-
performance_schema_max_digest_length
| Формат командной строки
| --performance_schema_max_digest_length=#
|
| Системная |
Имя |
performance_schema_max_digest_length |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
1024 |
| Минимум |
0 |
| Максимум |
1048576 |
Максимальное количество байтов, доступных для вычислительных обзоров
(см. раздел 23.7
). Эта переменная походит на
max_digest_length
, но относится только к Performance Schema.
Для получения дополнительной информации см. описание этой переменной в
разделе 6.1.5.
-
performance_schema_max_file_classes
| Формат командной строки
| --performance_schema_max_file_classes=#
|
| Системная |
Имя |
performance_schema_max_file_classes |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
80 |
Максимальное количество инструментов файла.
-
performance_schema_max_file_handles
| Формат командной строки
| --performance_schema_max_file_handles=#
|
| Системная |
Имя |
performance_schema_max_file_handles |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
32768 |
Максимальное количество открытых объектов файла.
Значение
performance_schema_max_file_handles должно быть больше, чем
значение open_files_limit
:
open_files_limit затрагивает максимальное количество открытых
дескрипторов, которые сервер может поддержать, а
performance_schema_max_file_handles указывает, сколько из этих
дескрипторов может быть инструментовано.
-
performance_schema_max_file_instances
| Формат командной строки
| --performance_schema_max_file_instances=#
|
| Системная |
Имя |
performance_schema_max_file_instances |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autoscaled) |
Максимальное количество инструментованных объектов файла.
-
performance_schema_max_index_stat
| Формат командной строки
| --performance_schema_max_index_stat=#
|
| Системная |
Имя |
performance_schema_max_index_stat |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autosized) |
Максимальное количество индексов, для которых Performance Schema
поддерживает статистику. Если этот максимум превышен, статистика индексов
потеряна, а Performance Schema постепенно увеличивает переменную
Performance_schema_index_stat_lost.
Значение по умолчанию задано, используя значение
performance_schema_max_table_instances.
-
performance_schema_max_memory_classes
| Формат командной строки
| --performance_schema_max_memory_classes=#
|
| Системная |
Имя |
performance_schema_max_memory_classes |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
320 |
Максимальное количество инструментов памяти.
-
performance_schema_max_metadata_locks
| Формат командной строки
| --performance_schema_max_metadata_locks=#
|
| Системная |
Имя |
performance_schema_max_metadata_locks |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autoscaled) |
Максимальное количество метаданных блокировки инструментов.
Это значение управляет размером таблицы
metadata_locks.
Если этот максимум превышен таким образом, что блокировка метаданных не может
быть инструментована, Performance Schema постепенно увеличивает
Performance_schema_metadata_lock_lost.
-
performance_schema_max_mutex_classes
| Формат командной строки
| --performance_schema_max_mutex_classes=#
|
| Системная |
Имя |
performance_schema_max_mutex_classes |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
200 |
Максимальное количество инструментов mutex.
-
performance_schema_max_mutex_instances
| Формат командной строки
| --performance_schema_max_mutex_instances=#
|
| Системная |
Имя |
performance_schema_max_mutex_instances |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autoscaled) |
Максимальное количество инструментованных объектов mutex.
-
performance_schema_max_prepared_statements_instances
| Формат командной строки
|
--performance_schema_max_prepared_statements_instances=# |
| Системная |
Имя |
performance_schema_max_prepared_statements_instances |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autoscaled) |
Максимальное количество строк в таблице
prepared_statements_instances. Если этот максимум превышен таким
образом, что готовый запрос не может быть инструментован, Performance Schema
постепенно увеличивает переменную
Performance_schema_prepared_statements_lost.
Значение по умолчанию этой переменной задано, основываясь на значении
переменной
max_prepared_stmt_count.
-
performance_schema_max_rwlock_classes
| Формат командной строки
| --performance_schema_max_rwlock_classes=#
|
| Системная |
Имя |
performance_schema_max_rwlock_classes |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
40 |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
20 |
Максимальное количество rwlock инструментов.
-
performance_schema_max_program_instances
| Формат командной строки
|
--performance_schema_max_program_instances=# |
| Системная |
Имя |
performance_schema_max_program_instances |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autoscaled) |
Максимальное количество сохраненных программ, для которых
Performance Schema поддерживает статистику. Если этот максимум превышен,
Performance Schema постепенно увеличивает переменную
Performance_schema_program_lost.
-
performance_schema_max_rwlock_instances
| Формат командной строки
| --performance_schema_max_rwlock_instances=#
|
| Системная |
Имя |
performance_schema_max_rwlock_instances |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autoscaled) |
Максимальное количество инструментованных объектов rwlock.
-
performance_schema_max_socket_classes
| Формат командной строки
| --performance_schema_max_socket_classes=#
|
| Системная |
Имя |
performance_schema_max_socket_classes |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
10 |
Максимальное количество инструментов сокета.
-
performance_schema_max_socket_instances
| Формат командной строки
| --performance_schema_max_socket_instances=#
|
| Системная |
Имя |
performance_schema_max_socket_instances |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autoscaled) |
Максимальное количество инструментованных объектов сокета.
-
performance_schema_max_sql_text_length
| Формат командной строки
| --performance_schema_max_sql_text_length=#
|
| Системная |
Имя |
performance_schema_max_sql_text_length |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
1024 |
| Минимум |
0 |
| Максимум |
1048576 |
Максимальное количество байтов, используемых, чтобы хранить запросы SQL в
столбце SQL_TEXT таблиц событий
events_statements_current,
events_statements_history и
events_statements_history_long. Любые байты сверх
performance_schema_max_sql_text_length отказаны и не появляются в
столбце SQL_TEXT. Запросы, отличающиеся только после этих
начальных байтов, неразличимы в этом столбце.
Уменьшение значения
performance_schema_max_sql_text_length
уменьшает использование памяти, но заставляет больше запросов становиться
неразличимыми, если они отличаются только в конце. Увеличение значения
увеличивает использование памяти, но разрешает более длинные
запросы, которые отличаются.
-
performance_schema_max_stage_classes
| Формат командной строки
| --performance_schema_max_stage_classes=#
|
| Системная |
Имя |
performance_schema_max_stage_classes |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
150 |
Максимальное количество инструментов этапа.
-
performance_schema_max_statement_classes
| Формат командной строки
| --performance_schema_max_statement_classes=# |
| Системная |
Имя |
performance_schema_max_statement_classes |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autosized) |
Максимальное количество инструментов запроса.
Значение по умолчанию вычислено в сервере, основываясь на числе команд в
протоколе клиент-сервер и числе типов запросов SQL, поддержанных сервером.
Эта переменная не должна быть заменена, если не установить ее в 0, чтобы
отключить всю инструментовку запросов и сохранить всю память, связанную с
нею. Установка переменной к ненулевым значениям кроме значения по умолчанию
не обладает никаким преимуществом, в частности значения, больше чем значение
по умолчанию, заставляют больше памяти быть выделенной.
-
performance_schema_max_statement_stack
| Формат командной строки
| --performance_schema_max_statement_stack=#
|
| Системная |
Имя |
performance_schema_max_statement_stack |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
10 |
Максимальная глубина вложенных вызовов сохраненных программ, для которых
Performance Schema поддерживает статистику. Когда этот максимум превышен,
Performance Schema постепенно увеличивает переменную
Performance_schema_nested_statement_lost для каждой
выполненной сохраненной программы.
-
performance_schema_max_table_handles
| Формат командной строки
| --performance_schema_max_table_handles=#
|
| Системная |
Имя |
performance_schema_max_table_handles |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autoscaled) |
Максимальное количество открытых табличных объектов. Это значение
управляет размером таблицы
table_handles.
Если этот максимум превышен таким образом, что табличный дескриптор не может
быть инструментован, Performance Schema постепенно увеличивает переменную
Performance_schema_table_handles_lost.
-
performance_schema_max_table_instances
| Формат командной строки
| --performance_schema_max_table_instances=#
|
| Системная |
Имя |
performance_schema_max_table_instances |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autoscaled) |
Максимальное количество инструментованных табличных объектов.
-
performance_schema_max_table_lock_stat
| Формат командной строки
| --performance_schema_max_table_lock_stat=#
|
| Системная |
Имя |
performance_schema_max_table_lock_stat |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autosized) |
Максимальное количество таблиц, для которых Performance Schema
поддерживает статистику блокировки. Если этот максимум превышен таким
образом, что табличные статистические данные блокировки потеряны,
Performance Schema увеличивает переменную
Performance_schema_table_lock_stat_lost.
-
performance_schema_max_thread_classes
| Формат командной строки
| --performance_schema_max_thread_classes=#
|
| Системная |
Имя |
performance_schema_max_thread_classes |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
50 |
Максимальное количество инструментов потока.
-
performance_schema_max_thread_instances
| Формат командной строки
| --performance_schema_max_thread_instances=#
|
| Системная |
Имя |
performance_schema_max_thread_instances |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autoscaled) |
Максимальное количество инструментованных объектов потока. Значение
управляет размером таблицы threads
. Если этот максимум превышен таким образом, что поток не может
быть инструментован, Performance Schema постепенно увеличивает переменную
Performance_schema_thread_instances_lost.
Переменная
max_connections затрагивает, сколько потоков может работать в
сервере.
performance_schema_max_thread_instances указывает,
сколько из этих рабочих потоков может быть инструментовано.
Таблицы
variables_by_thread и
status_by_thread содержат информацию только о потоках переднего
плана. Если не все потоки будут инструментованы Performance Schema,
то эта таблица пропустит некоторые строки. В этом случае переменная состояния
Performance_schema_thread_instances_lost
будет больше, чем ноль.
-
performance_schema_session_connect_attrs_size
| Формат командной строки
|
--performance_schema_session_connect_attrs_size=# |
| Системная |
Имя |
performance_schema_session_connect_attrs_size |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autosized) |
| Минимум |
-1 |
| Максимум |
1048576 |
Количество предварительно выделенной памяти на поток, чтобы держать
атрибуты соединения. Если совокупный размер данных о признаке соединения,
посланных клиентом, больше чем это количество, Performance Schema
усекает данные о признаке, увеличивая переменную
Performance_schema_session_connect_attrs_lost
и пишет сообщение в журнал ошибок, указывающее, что усечение произошло, если
переменная log_warnings
больше, чем ноль. Атрибут _truncated также добавлен к
признакам сеанса со значением, указывающим, сколько байтов было потеряно,
если у буфера признаков есть достаточное пространство. Это позволяет
Performance Schema выставить информацию об усечении на соединение в таблицах
атрибутов соединения. Эта информация может быть исследована, не имея
необходимость проверять журнал ошибок.
Значение по умолчанию
performance_schema_session_connect_attrs_size
задано при запуске сервера. Это значение может быть маленьким,
так, если усечение происходит
(
Performance_schema_session_connect_attrs_lost
становится отличным от нуля), Вы можете хотеть установить
performance_schema_session_connect_attrs_size
явно к большему значению.
Хотя максимум разрешенного значения
performance_schema_session_connect_attrs_size
составляет 1 МБ, эффективный максимум составляет 64 КБ, потому что сервер
налагает предел в 64 КБ на совокупный размер данных о признаке соединения.
Если клиент пытается послать больше чем 64 КБ данных о признаке, сервер
отклоняет соединение. Для получения дополнительной информации см.
раздел
23.9.9.
-
performance_schema_setup_actors_size
| Формат командной строки
| --performance_schema_setup_actors_size=#
|
| Системная |
Имя |
performance_schema_setup_actors_size |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autoscaled) |
Число строк в таблице
setup_actors.
-
performance_schema_setup_objects_size
| Формат командной строки
| --performance_schema_setup_objects_size=#
|
| Системная |
Имя |
performance_schema_setup_objects_size |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autoscaled) |
Число строк в таблице
setup_objects.
-
performance_schema_users_size
| Формат командной строки
| --performance_schema_users_size=#
|
| Системная |
Имя |
performance_schema_users_size |
| Область действия |
Глобальная |
| Динамическая |
Нет |
| Допустимые значения
| Тип |
integer |
| Значение по умолчанию |
-1 (autoscaled) |
| Минимум |
-1 (autoscaled) |
| Максимум |
1048576 |
Число строк в таблице users
. Если эта переменная 0, Performance Schema не поддерживает статистику
соединения в users
или информацию о переменных состояния в
status_by_user.
23.13.
Переменные состояния Performance Schema
Performance Schema осуществляет несколько переменных состояния, которые
предоставляют информацию об инструментовке, которая не могла быть загружена
или создана из-за ограничений памяти:
mysql> SHOW STATUS LIKE 'perf%';
+-------------------------------------------+-------+
| Variable_name | Value |
+-------------------------------------------+-------+
| Performance_schema_accounts_lost | 0 |
| Performance_schema_cond_classes_lost | 0 |
| Performance_schema_cond_instances_lost | 0 |
| Performance_schema_file_classes_lost | 0 |
| Performance_schema_file_handles_lost | 0 |
| Performance_schema_file_instances_lost | 0 |
| Performance_schema_hosts_lost | 0 |
| Performance_schema_locker_lost | 0 |
| Performance_schema_mutex_classes_lost | 0 |
| Performance_schema_mutex_instances_lost | 0 |
| Performance_schema_rwlock_classes_lost | 0 |
| Performance_schema_rwlock_instances_lost | 0 |
| Performance_schema_socket_classes_lost | 0 |
| Performance_schema_socket_instances_lost | 0 |
| Performance_schema_stage_classes_lost | 0 |
| Performance_schema_statement_classes_lost | 0 |
| Performance_schema_table_handles_lost | 0 |
| Performance_schema_table_instances_lost | 0 |
| Performance_schema_thread_classes_lost | 0 |
| Performance_schema_thread_instances_lost | 0 |
| Performance_schema_users_lost | 0 |
+-------------------------------------------+-------+
У переменных состояния Performance Schema есть следующие значения:
Performance_schema_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.
23.14.
Модель распределения памяти Performance Schema
Performance Schema использует эту модель распределения памяти:
Результат состоит в том, чтобы ослабить ограничения памяти так, чтобы
Performance Schema могла использоваться с меньшим количеством конфигурации, и
уменьшить расход памяти так, чтобы потребление масштабировалось с загрузкой
сервера. Используемая память зависит от загрузки, фактически замеченной, не
оцененной загрузки или явно сконфигурированный.
Несколько измеряющих параметров Performance Schema автомасштабируются и не
должны быть сконфигурированы явно, если Вы не хотите установить явный предел
на распределение памяти:
performance_schema_accounts_size
performance_schema_hosts_size
performance_schema_max_cond_instances
performance_schema_max_file_instances
performance_schema_max_index_stat
performance_schema_max_metadata_locks
performance_schema_max_mutex_instances
performance_schema_max_prepared_statements_instances
performance_schema_max_program_instances
performance_schema_max_rwlock_instances
performance_schema_max_socket_instances
performance_schema_max_table_handles
performance_schema_max_table_instances
performance_schema_max_table_lock_stat
performance_schema_max_thread_instances
performance_schema_users_size
Для автомасштабируемого параметра конфигурация работает так:
Чтобы видеть, сколько памяти использует Performance Schema,
проверьте инструменты, разработанные с этой целью. Performance Schema
выделяет память внутренне и связывает каждый буфер со специализированным
инструментом так, чтобы потребление памяти могло быть прослежено к отдельным
буферам. Инструменты с приставкой memory/performance_schema/
покажут, сколько памяти выделено для этих внутренних буферов. Буферы
глобальны для сервера, таким образом, инструменты выведены на экран только в
таблице
memory_summary_global_by_event_name, а не в других таблицах
memory_summary_by_xxx_by_event_name.
Этот запрос показывает информацию, связанную с инструментами памяти:
SELECT * FROM memory_summary_global_by_event_name
WHERE EVENT_NAME LIKE 'memory/performance_schema/%';
23.15.
Performance Schema и плагины
Удаление плагина с UNINSTALL
PLUGIN не затрагивает информацию, уже собранную для кода в этом
плагине. Время на выполнение кода, в то время как плагин был загружен, все
еще учтено, даже если плагин позже выгружен. Связанная информация о событии,
включая совокупную информацию, остается читаемой в таблицах базы данных
performance_schema. Для дополнительной информации об эффекте
установки и удаления плагина см.
раздел 23.5.
Конструктор плагина, который инструментует код, должен зарегистрировать
его характеристики инструментовки, чтобы позволить тем, кто загружает плагин,
составлять его требования. Например, имеющий отношение к третьей стороне
механизм хранения должен включать в документацию, в каком количестве памяти
механизм нуждается для mutex и других инструментов.
23.16.
Применение Performance Schema, чтобы диагностировать проблемы
Performance Schema инструмент, чтобы помочь DBA сделать работу, проводя
реальные измерения вместо примерных. Этот раздел, демонстрирует некоторые
способы использовать Performance Schema с этой целью. Обсуждение здесь
полагается на использование фильтрации событий, которая описана в
разделе 23.2.3.2.
Следующий пример обеспечивает одну методологию, которую Вы можете
использовать, чтобы проанализировать повторимую проблему, такую как
исследование исполнительного узкого места. Чтобы начать, у Вас должен быть
повторимый случай использования, где работу считают слишком медленной
и нуждающейся в оптимизации, и Вы должны включить всю инструментовку
(никакой предварительной фильтрации вообще).
Выполните случай использования. - Используя таблицы Performance Schema, проанализируйте первопричину
исполнительной проблемы. Этот анализ положится в большой
степени на постфильтрацию.
- Для проблемных областей, которые исключены, отключите соответствующие
инструменты. Например, если анализ показывает, что проблема не связана с
вводом/выводом файла в особом механизме хранения, отключите инструменты
ввода/вывода файла для этого механизма. Затем усеките историю и сводные
таблицы, чтобы удалить ранее собранные события.
- Повторите процесс в шаге 1.
При каждой итерации, вывод 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.
- Вы можете определить, какой поток держит mutex A:
SELECT * FROM mutex_instances
WHERE OBJECT_INSTANCE_BEGIN = mutex_A;
Скажите, что результат запроса идентифицирует, что это поток 2, который
держит mutex A, как найдено в
mutex_instances.LOCKED_BY_THREAD_ID.
- Вы можете видеть, что делает поток 2:
SELECT * FROM events_waits_current
WHERE THREAD_ID = thread_2;
23.16.1.
Профилирование запроса, используя Performance Schema
Следующий пример демонстрирует, как использовать события запросов
Performance Schema и события этапа, чтобы получить данные, сопоставимые с
профилированием информации, предоставленной
SHOW PROFILES и
SHOW PROFILE.
Таблица setup_actors
может использоваться, чтобы ограничить набор исторических событий узлом,
пользователем или учетной записью, чтобы уменьшить время выполнения
и объем данных, собранный в таблицах истории. Первый шаг примера показывает,
как ограничить набор исторических событий определенному пользователю.
Performance Schema выводит на экран информацию о таймере событий в
пикосекундах, чтобы нормализовать данные о синхронизации к стандартному
модулю. В следующем примере TIMER_WAIT разделены на
1000000000000, чтобы показать данные в модулях секунд. Значения являются
также усеченными к 6 десятичным разрядам, чтобы вывести на экран данные в том
же самом формате, как SHOW PROFILES
и SHOW PROFILE.
Ограничьте набор исторических событий пользователю,
который выполняет запрос. По умолчанию
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 |
+--------------------------------+----------+
23.17.
Переход к таблицам переменных системы и состояния Performance Schema
INFORMATION_SCHEMA имеет таблицы, которые содержат информацию
о переменных состояния (см. разделы
22.10 и 22.9). Performance Schema
также содержит таблицы переменных системы и состояния (см. разделы
23.9.13 и
23.9.14).
Таблицы Performance Schema предназначены, чтобы заменить
INFORMATION_SCHEMA, которые устарели с MySQL 5.7.6 и
будут удалены в будущем выпуске MySQL.
Этот раздел описывает намеченный миграционный путь с
INFORMATION_SCHEMA к соответствующим таблицам Performance
Schema. Разработчики приложений должны использовать эту информацию в качестве
руководства относительно изменений, требуемых, чтобы получить доступ к
системе и переменным состояния в MySQL.
MySQL 5.6
В MySQL 5.6 информация о переменных состояния доступна
через команду SHOW:
SHOW VARIABLES
SHOW STATUS
И через таблицы INFORMATION_SCHEMA:
INFORMATION_SCHEMA.GLOBAL_VARIABLES
INFORMATION_SCHEMA.SESSION_VARIABLES
INFORMATION_SCHEMA.GLOBAL_STATUS
INFORMATION_SCHEMA.SESSION_STATUS
MySQL 5.7
С MySQL 5.7.6 Performance Schema включает эти таблицы как новые источники
информации о переменных состояния:
performance_schema.global_variables
performance_schema.session_variables
performance_schema.variables_by_thread
performance_schema.global_status
performance_schema.session_status
performance_schema.status_by_thread
performance_schema.status_by_account
performance_schema.status_by_host
performance_schema.status_by_user
MySQL 5.7.6 также добавляет системную переменную
show_compatibility_56
, чтобы управлять, как сервер делает доступной
информацию о переменных состояния.
Когда
show_compatibility_56 ON, совместимость с MySQL 5.6
включена. Более старая система и источники переменных состояния
(запросы SHOW, таблицы INFORMATION_SCHEMA)
доступны с семантикой, идентичной MySQL 5.6. Приложения должны работать без
изменений кода и должен видеть те же самые имена переменных и значения, как в
MySQL 5.6. Предупреждения происходят при этих обстоятельствах:
Когда
show_compatibility_56 OFF,
совместимость с MySQL 5.6 отключена и несколько результатов изменены.
Приложения должны быть пересмотрены следующим образом, чтобы
работать должным образом:
Выбор из таблицы 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 потому, что это не будет существовать.
|
|
