MySQL 5.7版本说明
对于等待、阶段、语句和事务事件，Performance Schema可以监视和存储当前事件。此外，当事件结束时，Performance Schema可以将它们存储在历史表中。对于每种事件类型，性能模式使用三个表来存储当前和历史事件。这些表具有以下表单的名称，其中xxx事件类型(等待，阶段，语句，交易)：
events_:”时事”表存储每个线程的当前监视事件(每个线程一行)。xxx_currentevents_:”近年来的历史”表存储每个线程最近结束的事件(最多每个线程的最大行数)。xxx_historyevents_:”悠久的历史”表存储全局结束的最新事件(跨所有线程，最多每个表的最大行数)。xxx_history_long
的_current每个事件类型的表每个线程包含一行，因此没有用于配置其最大大小的系统变量。Performance Schema自动调整历史表的大小，或者可以在服务器启动时使用特定于表的系统变量显式配置历史表的大小，如描述各个历史表的部分所述。典型的自动大小值为每个线程10行_history表和10,000行的总和_history_long表。
对于每种事件类型，_current，_history,_history_long表具有相同的列。
的_current表显示了服务器中当前正在发生的事情。当前事件结束时，将从其_current表格
的_history而且_history_long表格显示了最近发生的事情。当历史表满时，旧事件将被丢弃，而新事件将被添加。的行过期。_history而且_history_long不同的表格，因为表格有不同的用途:
_history用于研究独立于全局服务器负载的单个线程。_history_long用于全局调查服务器，而不是每个线程。
这两种历史表之间的区别与数据保留策略有关。当第一次看到事件时，两个表包含相同的数据。然而，每个表中的数据随着时间的推移而过期，因此数据可能会在每个表中保存更长或更短的时间:
为
_history，当表包含给定线程的最大行数时，当为该线程添加新行时，最老的线程行将被丢弃。为
_history_long，当表满时，当添加新行时，最老的行将被丢弃，无论哪个线程生成了这两行。
线程结束时，其所有行将从_history表而不从_history_long表格
下面的示例说明了向两种类型的历史表添加事件和从其中丢弃事件的不同之处。这些原则同样适用于所有事件类型。本例基于以下假设:
的性能模式中每个线程保留10行
_history表中共有10,000行_history_long表格线程A每秒生成一个事件。
线程B每秒生成100个事件。
没有其他线程正在运行。
执行5秒后:
A和B分别产生了5和500个事件。
_historyA包含5行，B包含10行，因为每个线程的存储限制为10行，所以A没有丢弃任何行，而B则丢弃了490行。_history_longA包含5行，b包含500行。因为表的最大大小为10,000行，所以两个线程都没有丢弃任何行。
执行5分钟(300秒)后:
A和B分别生成了300和30,000个事件。
_history由于每个线程的存储限制为10行，因此A已经丢弃了290行，而B已经丢弃了29990行，A的行包括10秒前的数据，而B的行包括仅0.1秒前的数据。_history_long包含10,000行。因为A和B一起每秒生成101个事件，所以表中包含了大约10,000/101 = 99秒前的数据，其中来自B的行与来自A的行大约为100比1。