MySQL 9.0 发行说明
对于等待、阶段、语句和事务事件，Performance Schema 可以监控和存储当前事件。此外，当事件结束时，Performance Schema 可以将它们存储在历史表中。对于每种事件类型，Performance Schema 使用三个表来存储当前和历史事件。这些表的名称具有以下形式，其中 xxx 表示事件类型 (waits, stages, statements, transactions)
events_: “当前事件” 表存储每个线程的当前监控事件（每个线程一行）。xxx_currentevents_: “最近历史” 表存储每个线程已结束的最新的事件（每个线程最多存储一定数量的行）。xxx_historyevents_: “长时间历史” 表存储已结束的最新的全局事件（跨所有线程，每个表最多存储一定数量的行）。xxx_history_long
每种事件类型的 _current 表包含每个线程的一行，因此没有用于配置其最大大小的系统变量。Performance Schema 会自动调整历史表的大小，或者可以在服务器启动时使用特定于表的系统变量显式配置大小，如描述各个历史表的章节中所述。典型的自动调整大小值为每个线程 10 行（对于 _history 表），以及每个 _history_long 表总共 10,000 行。
对于每种事件类型，_current、_history 和 _history_long 表具有相同的列。_current 和 _history 表具有相同的索引。_history_long 表没有索引。
_current 表显示服务器中当前正在发生的事情。当当前事件结束时，它将从其 _current 表中删除。
_history 和 _history_long 表显示最近发生的事情。当历史表变得很满时，旧事件将被丢弃，以腾出空间添加新事件。_history 和 _history_long 表中的行以不同的方式过期，因为它们服务于不同的目的。
_history用于独立于全局服务器负载调查各个线程。_history_long用于全局调查服务器，而不是每个线程。
两种历史表之间的区别与数据保留策略有关。当首次看到事件时，两个表都包含相同的数据。但是，随着时间的推移，每个表中的数据过期方式不同，因此数据可能会在每个表中保留更长时间或更短时间。
对于
_history，当表包含给定线程的最大行数时，当为该线程添加新行时，最旧的线程行将被丢弃。对于
_history_long，当表变得很满时，最旧的行将被丢弃，以腾出空间添加新行，无论哪条线程生成这两行。
当线程结束时，其所有行将从 _history 表中丢弃，但不会从 _history_long 表中丢弃。
以下示例说明了事件如何添加到两种历史表中以及如何从两种历史表中丢弃。这些原理同样适用于所有事件类型。该示例基于以下假设。
Performance Schema 配置为在
_history表中每个线程保留 10 行，并在_history_long表中总共保留 10,000 行。线程 A 每秒生成 1 个事件。
线程 B 每秒生成 100 个事件。
没有其他线程正在运行。
执行 5 秒后
A 和 B 分别生成了 5 个和 500 个事件。
_history包含 A 的 5 行和 B 的 10 行。由于每个线程的存储空间限制为 10 行，因此 A 没有丢弃任何行，而 B 丢弃了 490 行。_history_long包含 A 的 5 行和 B 的 500 行。由于表的最大大小为 10,000 行，因此两个线程都没有丢弃任何行。
执行 5 分钟（300 秒）后
A 和 B 分别生成了 300 个和 30,000 个事件。
_history包含 A 的 10 行和 B 的 10 行。由于每个线程的存储空间限制为 10 行，因此 A 丢弃了 290 行，而 B 丢弃了 29,990 行。A 的行包括最长 10 秒前的數據，而 B 的行仅包含最长 0.1 秒前的數據。_history_long包含 10,000 行。由于 A 和 B 每秒总共生成 101 个事件，因此表包含最长约 10,000/101 = 99 秒前的數據，其中 B 相对于 A 的行数比例约为 100 比 1。