Таймеры Performance Schema различаются по точности и объёму накладных расходов. Чтобы увидеть доступные таймеры и их характеристики, см. таблицу 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 |
| THREAD_CPU  |       339101694 |                1 |            798 |
+-------------+-----------------+------------------+----------------+

Если значения, связанные с данным именем таймера, NULL, этот таймер не поддерживается на вашей платформе.

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

Performance Schema назначает таймеры следующим образом:

При запуске сервера Performance Schema проверяет, соответствуют ли предположения о назначении таймеров, сделанные на этапе компиляции, и выводит предупреждение, если таймер недоступен.

Для измерения событий ожидания важнейшим критерием является сокращение накладных расходов, возможно, в ущерб точности таймера, поэтому использование таймера 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, время отображается в пикосекундах (триллионных долях секунды), чтобы нормализовать его к стандартной единице независимо от выбранного таймера.

Базовая линия таймера (“нулевое время”) возникает во время инициализации 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, и что соответствующие потребители включены.