29.9 Performance Schema Tables for Current and Historical Events — MySQL 9.2

29.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 и _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 строки не удалялись, тогда как для B были удалены 490 строк.
_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 включают данные до .1 секунды.
_history_long содержит 10 000 строк. Поскольку A и B вместе генерируют 101 событие в секунду, таблица содержит данные приблизительно до 10 000/101 = 99 секунд, с перемешанными строками примерно от 100 до 1 от B по сравнению с A.