MySQL 8.3 Release Notes
对于等待、阶段、语句和事务事件，性能模式可以监控和存储当前事件。此外，当事件结束时，性能模式可以将其存储在历史表中。对于每种事件类型，性能模式使用三个表来存储当前和历史事件。这些表的名称如下，其中 xxx 表示事件类型 (waits, stages, statements, transactions):
-
events_: “当前事件” 表存储每个线程的当前监控事件（每个线程一行）。xxx_current -
events_: “最近历史” 表存储每个线程最近结束的事件（每个线程最多行数）。xxx_history -
events_: “长期历史” 表存储所有线程最近结束的事件（总共最多行数）。xxx_history_long
每种事件类型的 _current 表包含每个线程一行，因此没有系统变量来配置其最大大小。性能模式自动调整历史表的大小，或者可以在服务器启动时使用表特定的系统变量来显式配置大小，如每个历史表的描述部分所示。典型的自动调整值为每个线程 10 行的 _history 表和 10,000 行的 _history_long 表。
对于每种事件类型，_current、_history 和 _history_long 表具有相同的列。 _current 和 _history 表具有相同的索引。 _history_long 表没有索引。
_current 表显示服务器当前正在发生的事情。当当前事件结束时，它将从其 _current 表中删除。
_history 和 _history_long 表显示服务器最近过去发生的事情。当历史表满时，旧事件将被删除，以便添加新事件。 _history 和 _history_long 表中的行以不同的方式过期，因为这两个表具有不同的目的：
-
_history旨在独立于全局服务器负载的情况下调查单个线程。 -
_history_long旨在调查服务器的全局情况，而不是每个线程。
这两个历史表类型之间的差异与数据保留策略有关。两个表在事件首次出现时包含相同的数据。然而，数据在每个表中的过期方式不同，以便在每个表中保留数据的时间长短不同：
-
对于
_history，当表包含某个线程的最大行数时， oldest 线程行将被删除，以便添加新行。 -
对于
_history_long，当表满时， oldest 行将被删除，以便添加新行，无论生成行的线程是什么。
当线程结束时，其所有行将从 _history 表中删除，但不从 _history_long 表中删除。
以下示例说明了这两个历史表类型之间的差异。这些原则同样适用于所有事件类型。该示例基于以下假设：
-
性能模式配置为在
_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 倍。