MySQL 8.0版本说明
MySQL 8.0源代码文档10bet官方网站
通过添加到服务器源代码中的检测来收集事件。仪器对事件进行计时，这就是性能模式如何提供事件所需时间的概念。也可以配置仪器不收集定时信息。本节讨论可用的计时器及其特征，以及如何在事件中表示计时值。
性能模式计时器的精度和开销大小各不相同。要查看可用的计时器及其特性，请检查performance_timers表:
SELECT * FROM performance_schema.performance_timers;+-------------+-----------------+------------------+----------------+ | TIMER_NAME | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD | +-------------+-----------------+------------------+----------------+ | 周期| 2389029850 | 72 | | |纳秒| 1000000000 | 112 | | |微秒| 1000000 | | 136 | |毫秒| 1036 | 1 | 168 | +-------------+-----------------+------------------+----------------+如果与给定计时器名称相关的值为零，该计时器在您的平台上不支持。
这些列有以下含义:
的
TIMER_NAME列显示可用计时器的名称。周期是指基于CPU(处理器)周期计数器的定时器。TIMER_FREQUENCY每秒的定时器单位数。对于周期定时器，频率通常与CPU速度有关。所示的值是在2.4GHz处理器的系统上获得的。其他计时器是基于固定的秒数。TIMER_RESOLUTION表示每次增加的计时器单位的数量。如果定时器的分辨率为10，则其值每次增加10。TIMER_OVERHEAD是使用给定定时器获得一个定时所需的最小开销循环数。每个事件的开销是显示值的两倍，因为计时器在事件的开始和结束时调用。
性能架构分配定时器如下:
等待计时器使用
周期．空闲、阶段、语句和事务计时器使用的
纳秒在平台上纳秒计时器是可用的,微秒否则。
在服务器启动时，Performance Schema验证在构建时对计时器分配的假设是否正确，如果计时器不可用，则显示警告。
对于时间等待事件，最重要的标准是减少开销，而可能牺牲定时器的准确性，因此使用周期计时器是最好的。
一个语句(或阶段)执行所需的时间一般比执行单个等待所需的时间大几个数量级。对于时间语句，最重要的标准是有一个准确的测量，它不受处理器频率变化的影响，所以使用一个不基于周期的计时器是最好的。语句的缺省定时器为纳秒．额外的”开销”相比周期timer并不重要，因为调用两次计时器(一次在语句开始时，一次在语句结束时)所造成的开销比执行语句本身所用的CPU时间要小几个数量级。使用周期计时器在这里没有好处，只有缺点。
周期计数器提供的精度取决于处理器的速度。如果处理器以1ghz(十亿循环/秒)或更高的速度运行，则周期计数器提供亚纳秒的精度。使用自行车计数器比获取一天的实际时间便宜得多。例如，标准gettimeofday ()函数可能需要数百个周期，对于每秒可能发生数千次或数百万次的数据收集来说，这是不可接受的开销。
自行车计数器也有缺点:
终端用户希望看到以挂钟为单位的计时，比如几分之一秒。将周期转换为以秒为单位的单位是非常昂贵的。因此，转换是一个快速且相当粗略的乘法操作。
处理器循环速率可能会发生变化，例如当笔记本电脑进入省电模式或当CPU减慢速度以减少发热时。如果处理器的周期速率波动，则从周期到实时单位的转换容易出错。
根据处理器或操作系统的不同，周期计数器可能不可靠或不可用。例如，在Pentiums上，指令是
RDTSC(一种汇编语言而不是C指令)，从理论上讲，操作系统可以阻止用户模式程序使用它。一些与乱序执行或多处理器同步相关的处理器细节可能会导致计数器看起来快或慢多达1000个周期。
MySQL与x386 (Windows、macOS、Linux、Solaris和其他Unix版本)、PowerPC和IA-64上的循环计数器一起工作。
Performance Schema表中存储当前事件和历史事件的行有三列表示时间信息:TIMER_START而且TIMER_END指示事件开始和结束的时间TIMER_WAIT表示事件持续时间。
的setup_instruments表有一个启用列，指示用来收集事件的工具。桌子上也有一个定时列表示哪些仪器是计时的。如果仪器未启用，则不会产生事件。如果已启用的仪器没有计时，则由该仪器产生的事件将有零为TIMER_START，TIMER_END,TIMER_WAIT定时器值。这又会导致在计算汇总表中的聚合时间值(和、最小值、最大值和平均值)时忽略这些值。
在内部，事件中的时间以计时器给出的单位存储，该计时器在事件计时开始时生效。为了在从Performance Schema表中检索事件时显示，时间以皮秒(万亿分之一秒)为单位显示，以将它们规范化为标准单位，而不管选择哪个计时器。
计时器基线(”时间为零”)发生在服务器启动期间的性能架构初始化时。TIMER_START而且TIMER_END事件中的值表示距离基线的皮秒。TIMER_WAIT值是以皮秒为单位的持续时间。
事件中的皮秒值是近似值。它们的准确性受制于从一个单位转换到另一个单位的通常形式的误差。如果周期使用定时器和处理器速率变化，可能会有漂移。基于这些原因，我们不应该只看TIMER_START值，作为服务器启动后所经过时间的精确度量。另一方面，它是合理的使用TIMER_START或TIMER_WAIT值命令子句按开始时间或持续时间对事件排序。
在事件中选择皮秒而不是像微秒这样的值具有性能基础。实现的一个目标是在统一的时间单位中显示结果，而不考虑计时器。在理想的情况下，这个时间单位应该像挂钟一样，相当精确;换句话说，微秒。但是要将周期或纳秒转换为微秒，就必须对每个仪器执行除法。在许多平台上，分裂是昂贵的。乘法并不昂贵，所以用的就是乘法。因此，时间单位是可能最大值的整数倍TIMER_FREQUENCY值，使用一个足够大的乘数，以确保没有重大的精度损失。结果是时间单位为”皮秒。”这种精确度是虚假的，但该决策使开销最小化。
当等待、阶段、语句或事务事件正在执行时，各自的当前事件表显示当前事件计时信息:
Events_waits_current events_stages_current events_statements_current events_transactions_current为了能够确定一个尚未完成的事件已经运行了多长时间，计时器列设置如下:
TIMER_START填充。TIMER_END使用当前计时器值填充。TIMER_WAIT填充到目前为止所经过的时间(TIMER_END−TIMER_START）.
尚未完成的事件具有END_EVENT_ID的价值零．要评估事件到目前为止所花费的时间，请使用TIMER_WAIT列。因此，要确定尚未完成的事件和花费的时间超过N到目前为止，监视应用程序可以在查询中使用这个表达式:
end_event_id为空，timer_wait >N刚刚描述的事件识别假设相应的仪器有启用而且定时设置为是的并且启用了相关的消费者。