События собираются посредством инструментария, добавленного к исходному коду сервера. Инструментальные события времени, который является, как Схема Производительности обеспечивает идею того, сколько времени события берут. Также возможно сконфигурировать инструменты, чтобы не собрать информацию синхронизации. Этот раздел обсуждает доступные таймеры и их характеристики, и как значения синхронизации представляются в событиях.

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

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

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

mysql> SELECT * FROM
        performance_timers;+-------------+-----------------+------------------+----------------+| TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |+-------------+-----------------+------------------+----------------+| CYCLE       |      2389029850 |                1 |             72 || NANOSECOND  |            NULL |             NULL |           NULL || MICROSECOND |         1000000 |                1 |            585 || MILLISECOND |            1035 |                1 |            738 || TICK        |             101 |                1 |            630 |+-------------+-----------------+------------------+----------------+

TIMER_NAME столбец показывает имена доступных таймеров. CYCLE обращается к таймеру, который основан на ЦП (процессор) счетчик циклов. Если значения, связанные с данным именем таймера, NULL, тот таймер не поддерживается на Вашей платформе. Строки, которые не имеют NULL укажите, в каких таймерах можно использовать setup_timers.

TIMER_FREQUENCY указывает на число модулей таймера в секунду. Для счетчика циклов частота обычно связывается со скоростью ЦП. Показанное значение было получено на системе с 2.4GHz процессор. Другие таймеры основаны на фиксированных частях секунд. Для TICK, частота может измениться платформой (например, некоторое использование 100 галочек / второй, другие 1000 галочек / второй).

TIMER_RESOLUTION указывает на число модулей таймера, которыми таймер оценивает увеличение за один раз. Если у таймера есть разрешение 10, его увеличения значения к 10 каждым разам.

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

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

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

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

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

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

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

У счетчиков циклов также есть недостатки:

В настоящий момент MySQL работает со счетчиками циклов над x386 (Windows, Mac OS X, Linux, Солярис, и другие разновидности Unix), PowerPC, и IA-64.

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

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

Модификации к setup_timers таблица сразу влияет на контроль. События уже в продвижении используют исходный таймер в течение начать времени и новый таймер в течение времени окончания, которое приводит к непредсказуемым результатам. Если Вы производите изменения таймера, можно хотеть использовать TRUNCATE TABLE сбрасывать статистику Схемы Производительности.

Базовая линия таймера ("нуль времени") происходит в инициализации Схемы Производительности во время запуска сервера. TIMER_START и TIMER_END значения в событиях представляют пикосекунды начиная с базовой линии. TIMER_WAIT значения являются продолжительностями в пикосекундах.

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

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