MySQL 8.4 Release Notes
对于等待、阶段、语句和事务事件，性能架构可以监控并存储当前事件。此外，当事件结束时，性能架构可以将其存储在历史表中。对于每种事件类型，性能架构使用三个表来存储当前和历史事件。这些表的名称形式如下，其中 xxx 表示事件类型（waits、stages、statements、transactions）：For wait, stage, statement, and transaction events, the
Performance Schema can monitor and store current events. In
addition, when events end, the Performance Schema can store them
in history tables. For each event type, the Performance Schema
uses three tables for storing current and historical events. The
tables have names of the following forms, where
xxx indicates the event type
(waits, stages,
statements, transactions):
events_：“当前事件” 表存储每个线程的当前监控事件（每个线程一行）。xxx_currentevents_: The “current events” table stores the current monitored event for each thread (one row per thread).xxx_currentevents_：“最近历史” 表存储每个线程中已结束的最新事件（每个线程最多存储一定数量的行）。xxx_historyevents_: The “recent history” table stores the most recent events that have ended per thread (up to a maximum number of rows per thread).xxx_historyevents_：“长期历史” 表存储全局（跨所有线程）已结束的最新事件（每个表最多存储一定数量的行）。xxx_history_longevents_: The “long history” table stores the most recent events that have ended globally (across all threads, up to a maximum number of rows per table).xxx_history_long
每个事件类型的 _current 表包含每个线程的一行，因此没有系统变量可以配置其最大大小。Performance Schema 会自动调整历史表的大小，或者可以在服务器启动时使用表特定的系统变量显式配置其大小，如描述各个历史表的部分所示。典型的自动调整值是每个线程的 _history 表为 10 行，总共 _history_long 表为 10,000 行。The _current table for each event type contains
one row per thread, so there is no system variable for configuring
its maximum size. The Performance Schema autosizes the history
tables, or the sizes can be configured explicitly at server
startup using table-specific system variables, as indicated in the
sections that describe the individual history tables. Typical
autosized values are 10 rows per thread for
_history tables, and 10,000 rows total for
_history_long tables.
对于每个事件类型，_current、_history 和 _history_long 表具有相同的列。_current 和 _history 表具有相同的索引。_history_long 表没有索引。For each event type, the _current,
_history, and _history_long
tables have the same columns. The _current and
_history tables have the same indexing. The
_history_long table has no indexing.
_current 表显示服务器中当前正在发生的情况。当当前事件结束时，它会从其 _current 表中移除。The _current tables show what is currently
happening within the server. When a current event ends, it is
removed from its _current table.
_history 和 _history_long 表显示最近发生的事件。当历史表已满时，旧事件会在新事件添加时被丢弃。_history 和 _history_long 表中的行过期方式不同，因为这些表的用途不同：The _history and
_history_long tables show what has happened in
the recent past. When the history tables become full, old events
are discarded as new events are added. Rows expire from the
_history and _history_long
tables in different ways because the tables serve different
purposes:
_history用于独立于全局服务器负载调查各个线程。_historyis meant to investigate individual threads, independently of the global server load._history_long用于全局调查服务器，而不是每个线程。_history_longis meant to investigate the server globally, not each thread.
这两种历史表的区别与数据保留策略有关。两张表在首次检测到事件时包含相同的数据。然而，每张表中的数据随时间到期的方式不同，因此数据在每张表中可能保存的时间长短不同：The difference between the two types of history tables relates to the data retention policy. Both tables contains the same data when an event is first seen. However, data within each table expires differently over time, so that data might be preserved for a longer or shorter time in each table:
对于
_history，当表中某个线程的行数达到最大值时，当为该线程添加新行时，最旧的线程行将被丢弃。For_history, when the table contains the maximum number of rows for a given thread, the oldest thread row is discarded when a new row for that thread is added.对于
_history_long，当表满时，无论哪条线程生成了行，添加新行时都会丢弃最旧的行。For_history_long, when the table becomes full, the oldest row is discarded when a new row is added, regardless of which thread generated either row.
当线程结束时，其所有行将从 _history 表中删除，但不会从 _history_long 表中删除。When a thread ends, all its rows are discarded from the
_history table but not from the
_history_long table.
以下示例说明了事件在两种类型的历史表中是如何添加和丢弃的差异。原则同样适用于所有事件类型。该示例基于以下假设：The following example illustrates the differences in how events are added to and discarded from the two types of history tables. The principles apply equally to all event types. The example is based on these assumptions:
Performance Schema 配置为在
_history表中每个线程保留 10 行，在_history_long表中总共保留 10,000 行。The Performance Schema is configured to retain 10 rows per thread in the_historytable and 10,000 rows total in the_history_longtable.线程 A 每秒生成 1 个事件。Thread A generates 1 event per second.
线程 B 每秒生成 100 个事件。Thread B generates 100 events per second.
没有其他线程在运行。No other threads are running.
执行 5 秒后：After 5 seconds of execution:
A 和 B 分别生成了 5 个和 500 个事件。A and B have generated 5 and 500 events, respectively.
_history表中，A 有 5 行，B 有 10 行。由于每个线程的存储限制为 10 行，A 没有被丢弃的行，而 B 有 490 行被丢弃。_historycontains 5 rows for A and 10 rows for B. Because storage per thread is limited to 10 rows, no rows have been discarded for A, whereas 490 rows have been discarded for B._history_long包含 A 的 5 行和 B 的 500 行。因为该表的最大大小为 10,000 行，所以两个线程都没有丢弃任何行。_history_longcontains 5 rows for A and 500 rows for B. Because the table has a maximum size of 10,000 rows, no rows have been discarded for either thread.
执行 5 分钟（300 秒）后：After 5 minutes (300 seconds) of execution:
A 和 B 分别生成了 300 和 30,000 个事件。A and B have generated 300 and 30,000 events, respectively.
_history包含 A 的 10 行和 B 的 10 行。因为每个线程的存储限制为 10 行，A 丢弃了 290 行，而 B 丢弃了 29,990 行。A 的行包含最多 10 秒前的数据，而 B 的行仅包含最多 0.1 秒前的数据。_historycontains 10 rows for A and 10 rows for B. Because storage per thread is limited to 10 rows, 290 rows have been discarded for A, whereas 29,990 rows have been discarded for B. Rows for A include data up to 10 seconds old, whereas rows for B include data up to only .1 seconds old._history_long包含 10,000 行。因为 A 和 B 一起每秒生成 101 个事件，该表包含的数据大约有 10,000/101 = 99 秒前的数据，行的组合约为 B:A = 100:1。_history_longcontains 10,000 rows. Because A and B together generate 101 events per second, the table contains data up to approximately 10,000/101 = 99 seconds old, with a mix of rows approximately 100 to 1 from B as opposed to A.