25.9 Performance Schema Tables for Current and Historical Events — MySQL 5.7

25.9 Таблицы Performance Schema для текущих и исторических событий

Для событий ожидания, стадии, оператора и транзакции Performance Schema может отслеживать и хранить текущие события. Кроме того, по завершении событий Performance Schema может сохранять их в таблицах истории. Для каждого типа событий Performance Schema использует три таблицы для хранения текущих и исторических событий. Таблицы имеют названия следующего формата, где xxx указывает тип события (waits, stages, statements, transactions):

events_xxx_current: Таблица “текущих событий” хранит текущее отслеживаемое событие для каждого потока (одна строка на поток).
events_xxx_history: Таблица “недавней истории” хранит самые последние завершенные события на поток (до максимального числа строк на поток).
events_xxx_history_long: Таблица “длительной истории” хранит самые последние завершенные события глобально (по всем потокам, до максимального числа строк в таблице).

Таблица _current для каждого типа события содержит по одной строке на поток, поэтому для ее максимального размера нет переменной системы. Performance Schema автоматически настраивает размеры таблиц истории, или размеры можно настроить явно при запуске сервера с помощью переменных системы, специфичных для таблицы, как указано в разделах, описывающих отдельные таблицы истории. Типичные значения с автоматическим размером составляют 10 строк на поток для таблиц _history и 10 000 строк в общей сложности для таблиц _history_long.

Для каждого типа события таблицы _current, _history и _history_long имеют одинаковые столбцы.

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

Таблицы _history и _history_long показывают, что происходило в недавнем прошлом. Когда таблицы истории заполняются, старые события удаляются по мере добавления новых. Строки истекают из таблиц _history и _history_long различными способами, поскольку таблицы служат различным целям:

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

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

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

Когда поток завершается, все его строки удаляются из таблицы _history, но не из таблицы _history_long.

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

Performance Schema настроен на сохранение 10 строк на поток в таблице _history и 10 000 строк в общей сложности в таблице _history_long.
Поток A генерирует 1 событие в секунду.

Поток B генерирует 100 событий в секунду.
Других потоков не запущено.

После 5 секунд выполнения:

A и B сгенерировали соответственно 5 и 500 событий.
_history содержит 5 строк для A и 10 строк для B. Поскольку хранение на поток ограничено 10 строками, для A не было удалено строк, в то время как 490 строк были удалены для B.
_history_long содержит 5 строк для A и 500 строк для B. Поскольку максимальный размер таблицы составляет 10 000 строк, для обоих потоков не было удалено строк.

После 5 минут (300 секунд) выполнения:

A и B сгенерировали соответственно 300 и 30 000 событий.
_history содержит 10 строк для A и 10 строк для B. Поскольку хранение на поток ограничено 10 строками, 290 строк были удалены для A, в то время как 29 990 строк были удалены для B. Строки для A включают данные до 10 секунд в возрасте, в то время как строки для B включают данные до всего лишь 0,1 секунды в возрасте.
_history_long содержит 10 000 строк. Поскольку A и B вместе генерируют 101 событие в секунду, таблица содержит данные до примерно 10 000/101 = 99 секунд в возрасте, со смешением строк примерно от 100 до 1 от B по сравнению с A.