性能模式计时器在精度和开销量上有所不同。要查看可用的计时器及其特性，请查看performance_timers表：Performance Schema timers vary in precision and amount of overhead. To see what timers are available and their characteristics, check the performance_timers table:

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，则表示在您的平台上该计时器不受支持。If the values associated with a given timer name are NULL, that timer is not supported on your platform.

这些列的含义如下：The columns have these meanings:

性能模式分配计时器如下：The Performance Schema assigns timers as follows:

在服务器启动时，性能模式会验证在构建时对计时器分配所做的假设是否正确，如果计时器不可用，则显示警告。At server startup, the Performance Schema verifies that assumptions made at build time about timer assignments are correct, and displays a warning if a timer is not available.

为了对事件进行计时，最重要的标准是尽可能减少开销，即使可能以牺牲计时器的精度为代价，因此使用CYCLE计时器是最好的。To time wait events, the most important criterion is to reduce overhead, at the possible expense of the timer accuracy, so using the CYCLE timer is the best.

语句（或阶段）执行所需的时间通常比执行一次等待所需的时间大几个数量级。对语句进行计时时，最重要的标准是有一个准确的测量，不受处理器频率变化的影响，因此使用不基于周期的计时器是最好的。语句的默认计时器是NANOSECOND。与CYCLE计时器相比，额外的“开销”并不显著，因为调用计时器两次（一次在语句开始时，一次在语句结束时）引起的开销相比执行语句本身所用的 CPU 时间要小几个数量级。这里使用CYCLE计时器没有任何好处，只有缺点。The time a statement (or stage) takes to execute is in general orders of magnitude larger than the time it takes to execute a single wait. To time statements, the most important criterion is to have an accurate measure, which is not affected by changes in processor frequency, so using a timer which is not based on cycles is the best. The default timer for statements is NANOSECOND. The extra “overhead” compared to the CYCLE timer is not significant, because the overhead caused by calling a timer twice (once when the statement starts, once when it ends) is orders of magnitude less compared to the CPU time used to execute the statement itself. Using the CYCLE timer has no benefit here, only drawbacks.

周期计数器提供的精度取决于处理器速度。如果处理器运行在 1 GHz（十亿次/秒）或更高频率，周期计数器可以提供亚纳秒精度。使用周期计数器比获取实际的时间要便宜得多。例如，标准的 gettimeofday() 函数可能需要几百个周期，这对于每秒可能发生数千次或数百万次的数据采集来说，是不可接受的开销。The precision offered by the cycle counter depends on processor speed. If the processor runs at 1 GHz (one billion cycles/second) or higher, the cycle counter delivers sub-nanosecond precision. Using the cycle counter is much cheaper than getting the actual time of day. For example, the standard gettimeofday() function can take hundreds of cycles, which is an unacceptable overhead for data gathering that may occur thousands or millions of times per second.

周期计数器也有一些缺点：Cycle counters also have disadvantages:

MySQL 在 x386（Windows、macOS、Linux、Solaris 以及其他 Unix 系统）、PowerPC 和 IA-64 上都可以使用周期计数器。MySQL works with cycle counters on x386 (Windows, macOS, Linux, Solaris, and other Unix flavors), PowerPC, and IA-64.

存储当前事件和历史事件的性能模式表中的行有三列用于表示时间信息：TIMER_START 和 TIMER_END 表示事件的开始和结束时间，而 TIMER_WAIT 表示事件持续时间。Rows in Performance Schema tables that store current events and historical events have three columns to represent timing information: TIMER_START and TIMER_END indicate when an event started and finished, and TIMER_WAIT indicates event duration.

setup_instruments 表有一个 ENABLED 列，用于指示需要收集事件的工具。该表还有一个 TIMED 列，用于指示哪些工具是计时的。如果某个工具未启用，则不会产生任何事件。如果启用的工具未计时，则该工具产生的事件在 TIMER_START、TIMER_END 和 TIMER_WAIT 定时器值为 NULL。这会导致在汇总表（总和、最小值、最大值和平均值）中计算聚合时间值时忽略这些值。The setup_instruments table has an ENABLED column to indicate the instruments for which to collect events. The table also has a TIMED column to indicate which instruments are timed. If an instrument is not enabled, it produces no events. If an enabled instrument is not timed, events produced by the instrument have NULL for the TIMER_START, TIMER_END, and TIMER_WAIT timer values. This in turn causes those values to be ignored when calculating aggregate time values in summary tables (sum, minimum, maximum, and average).

在内部，事件中的时间以事件计时开始时所使用的计时器所给的单位存储。为了在从 Performance Schema 表中检索事件时显示，时间以皮秒（万亿分之一秒）表示，以将它们统一为标准单位，无论选择哪种计时器。Internally, times within events are stored in units given by the timer in effect when event timing begins. For display when events are retrieved from Performance Schema tables, times are shown in picoseconds (trillionths of a second) to normalize them to a standard unit, regardless of which timer is selected.

计时器基准（“时间零点”）发生在服务器启动期间 Performance Schema 初始化时。事件中的 TIMER_START 和 TIMER_END 值表示自基准以来的皮秒。TIMER_WAIT 值是以皮秒为单位的持续时间。The timer baseline (“time zero”) occurs at Performance Schema initialization during server startup. TIMER_START and TIMER_END values in events represent picoseconds since the baseline. TIMER_WAIT values are durations in picoseconds.

事件中的皮秒值是近似的。它们的准确性受从一个单位转换到另一个单位时通常存在的各种误差影响。如果使用CYCLE计时器且处理器速率变化，可能会出现漂移。因此，将事件的TIMER_START值作为自服务器启动以来的精确时间测量是不合理的。另一方面，在TIMER_START子句中使用TIMER_WAIT或ORDER BY值按开始时间或持续时间对事件排序是合理的。Picosecond values in events are approximate. Their accuracy is subject to the usual forms of error associated with conversion from one unit to another. If the CYCLE timer is used and the processor rate varies, there might be drift. For these reasons, it is not reasonable to look at the TIMER_START value for an event as an accurate measure of time elapsed since server startup. On the other hand, it is reasonable to use TIMER_START or TIMER_WAIT values in ORDER BY clauses to order events by start time or duration.

在事件中选择皮秒而不是微秒等值，是有性能依据的。一个实现目标是无论计时器如何，都能以统一的时间单位显示结果。在理想情况下，这个时间单位应该像挂钟单位一样，并且相当精确；换句话说，就是微秒。但是，要将周期或纳秒转换为微秒，就需要对每个仪器操作进行一次除法。除法在许多平台上开销很大。乘法开销不大，所以选择使用乘法。因此，这个时间单位是最高可能的TIMER_FREQUENCY值的整数倍，使用足够大的乘数以确保没有重大精度损失。结果是，这个时间单位是“皮秒。”这种精度是虚假的，但这个决定可以最小化开销。The choice of picoseconds in events rather than a value such as microseconds has a performance basis. One implementation goal was to show results in a uniform time unit, regardless of the timer. In an ideal world this time unit would look like a wall-clock unit and be reasonably precise; in other words, microseconds. But to convert cycles or nanoseconds to microseconds, it would be necessary to perform a division for every instrumentation. Division is expensive on many platforms. Multiplication is not expensive, so that is what is used. Therefore, the time unit is an integer multiple of the highest possible TIMER_FREQUENCY value, using a multiplier large enough to ensure that there is no major precision loss. The result is that the time unit is “picoseconds.” This precision is spurious, but the decision enables overhead to be minimized.

当等待、阶段、语句或事务事件正在执行时，相应的当前事件表会显示当前事件的时间信息：While a wait, stage, statement, or transaction event is executing, the respective current-event tables display current-event timing information:

events_waits_current
events_stages_current
events_statements_current
events_transactions_current

为了能够确定尚未完成的事件已经运行了多长时间，计时器列设置如下：To make it possible to determine how long a not-yet-completed event has been running, the timer columns are set as follows:

尚未完成的事件其 END_EVENT_ID 值为 NULL。要评估事件到目前为止经过的时间，请使用 TIMER_WAIT 列。因此，要识别尚未完成且到目前为止已耗时超过 N 皮秒的事件，监控应用程序可以在查询中使用此表达式：Events that have not yet completed have an END_EVENT_ID value of NULL. To assess time elapsed so far for an event, use the TIMER_WAIT column. Therefore, to identify events that have not yet completed and have taken longer than N picoseconds thus far, monitoring applications can use this expression in queries:

WHERE END_EVENT_ID IS NULL AND TIMER_WAIT > N

如上所述的事件识别假定相应的仪器已将 ENABLED 和 TIMED 设置为 YES，并且相关的消费者已启用。Event identification as just described assumes that the corresponding instruments have ENABLED and TIMED set to YES and that the relevant consumers are enabled.