Таймеры схемы производительности различаются по точности и объему накладных расходов. Чтобы узнать, какие таймеры доступны и их характеристики, проверьте таблицу 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, этот таймер не поддерживается на вашей платформе.

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

Схема производительности назначает таймеры следующим образом:

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

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

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

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

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

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

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

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

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

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