Две таблицы схемы Performance предоставляют информацию о таймерах:

Каждая строка таймера в setup_timers должна ссылаться на один из таймеров, перечисленных в performance_timers.

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

mysql> SELECT * FROM performance_schema.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 |
+-------------+-----------------+------------------+----------------+

Если значения, связанные с данным именем таймера, NULL, то этот таймер не поддерживается на вашей платформе. Строки, не содержащие NULL, указывают, какие таймеры можно использовать в setup_timers.

Столбцы имеют следующие значения:

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

mysql> SELECT * FROM performance_schema.setup_timers;
+-------------+-------------+
| NAME        | TIMER_NAME  |
+-------------+-------------+
| idle        | MICROSECOND |
| wait        | CYCLE       |
| stage       | NANOSECOND  |
| statement   | NANOSECOND  |
| transaction | NANOSECOND  |
+-------------+-------------+

mysql> UPDATE performance_schema.setup_timers
       SET TIMER_NAME = 'MICROSECOND'
       WHERE NAME = 'idle';
mysql> SELECT * FROM performance_schema.setup_timers;
+-------------+-------------+
| NAME        | TIMER_NAME  |
+-------------+-------------+
| idle        | MICROSECOND |
| wait        | CYCLE       |
| stage       | NANOSECOND  |
| statement   | NANOSECOND  |
| transaction | NANOSECOND  |
+-------------+-------------+

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

Для измерения событий ожидания наиболее важным критерием является сокращение накладных расходов, возможно, за счет точности таймера, поэтому использование таймера CYCLE является лучшим вариантом.

Время выполнения оператора (или этапа) обычно на несколько порядков больше времени выполнения одного ожидания. Для измерения операторов наиболее важным критерием является получение точного измерения, не зависящего от изменения частоты процессора, поэтому использование таймера, не основанного на циклах, является наилучшим вариантом. По умолчанию для операторов используется таймер NANOSECOND. Дополнительные “накладные расходы” по сравнению с таймером CYCLE несущественны, так как накладные расходы, вызванные вызовом таймера дважды (один раз при запуске оператора, один раз при его завершении), на несколько порядков меньше по сравнению со временем, затрачиваемым процессором на выполнение самого оператора. Использование таймера CYCLE здесь не принесёт пользы, только недостатки.

Точность, предоставляемая счетчиком циклов, зависит от скорости процессора. Если процессор работает на частоте 1 ГГц (один миллиард циклов/сек) или выше, счетчик циклов обеспечивает точность до долей наносекунды. Использование счетчика циклов намного дешевле, чем получение реального времени.

Например, стандартная функция gettimeofday() может занять сотни циклов, что является неприемлемыми накладными расходами для сбора данных, которые могут происходить тысячи или миллионы раз в секунду.

Счетчики циклов также имеют недостатки:

MySQL работает со счетчиками циклов на x386 (Windows, macOS, Linux, Solaris и других вариантах Unix), PowerPC и IA-64.

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

Таблица setup_instruments имеет столбец ENABLED, чтобы указать инструменты, для которых необходимо собирать события. Таблица также имеет столбец TIMED, чтобы указать, какие инструменты отслеживаются по времени. Если инструмент не включен, он не генерирует события. Если включенный инструмент не отслеживается по времени, события, созданные этим инструментом, имеют значение NULL для TIMER_START, TIMER_END и TIMER_WAIT значений таймера. Это, в свою очередь, приводит к тому, что эти значения игнорируются при расчёте агрегированных значений времени в сводных таблицах (сумма, минимум, максимум и среднее значение).

Внутренне, время в событиях хранится в единицах, задаваемых таймером, действующим в момент начала отслеживания события. При получении событий из таблиц Performance Schema время отображается в пикосекундах (триллионных долях секунды), чтобы привести его к стандартной единице измерения независимо от выбранного таймера.

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

Базовая линия таймера («“время ноль”) устанавливается при инициализации Performance Schema во время запуска сервера. TIMER_START и TIMER_END значения в событиях представляют пикосекунды, прошедшие с момента базовой линии. TIMER_WAIT значения представляют длительность в пикосекундах.

Значения в пикосекундах в событиях являются приблизительными. Их точность зависит от обычных ошибок, связанных с преобразованием из одной единицы измерения в другую. Если используется таймер CYCLE и частота процессора меняется, может произойти дрейф. По этим причинам, рассматривать значение TIMER_START события как точное измерение времени, прошедшего с момента запуска сервера, нецелесообразно. С другой стороны, целесообразно использовать TIMER_START или TIMER_WAIT значения в ORDER BY клаузах для сортировки событий по времени начала или продолжительности.

Выбор пикосекунд в событиях вместо, например, микросекунд обусловлен производительностью. Одна из целей реализации заключалась в отображении результатов в единой единице времени независимо от таймера. В идеальном мире эта единица времени должна быть похожа на реальное время и достаточно точной; другими словами, микросекунды. Но для преобразования циклов или наносекунд в микросекунды необходимо выполнять деление для каждого инструментария. Деление является дорогостоящим на многих платформах. Умножение не является дорогостоящим, поэтому оно и используется. Таким образом, единицей времени является целое кратное максимальному возможному значению TIMER_FREQUENCY, используя достаточно большое значение множителя, чтобы не допустить значительной потери точности. В результате, единицей времени являются “пикосекунды.” Эта точность является излишней, но это решение позволяет минимизировать накладные расходы.

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

events_waits_current
events_stages_current
events_statements_current
events_transactions_current

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

У событий, которые еще не завершены, значение END_EVENT_ID равно NULL. Чтобы оценить прошедшее время события, используйте столбец TIMER_WAIT. Таким образом, чтобы определить события, которые еще не завершены и заняли более N пикосекунд, приложения мониторинга могут использовать это выражение в запросах:

WHERE END_EVENT_ID IS NULL AND TIMER_WAIT > N

Определение события, как описано выше, предполагает, что соответствующие инструменты имеют ENABLED и TIMED установлены в YES, и что соответствующие потребители включены.