25.12.7 性能架构事务 table

性能架构对事务进行检测。在事件层次结构中，await 事件嵌套在阶段事件内，嵌套在语句事件内，嵌套在事务事件内。

这些 table 存储事务事件：

events_transactions_current：每个线程的当前事务事件。
events_transactions_history：每个线程已结束的最新事务事件。
events_transactions_history_long：全局(在所有线程中)结束的最新事务事件。

以下各节描述了事务事件 table。也有汇总 table，汇总有关 Transaction 事件的信息。参见第 25.12.15.4 节“事务摘要 table”。

有关三个事务事件 table 之间的关系的更多信息，请参见第 25.9 节“当前和历史事件的性能架构 table”。

配置事务事件整理

要控制是否收集 Transaction 事件，请设置相关工具和使用者的状态：

setup_instrumentstable 包含名为transaction的工具。使用此工具可以启用或禁用单个 Transaction 事件类的收集。
setup_consumerstable 包含名称与当前和历史事务事件 table 名称相对应的使用者值。使用这些使用者来筛选事务事件的集合。

默认情况下，禁用transaction工具和 Transaction 使用者：

mysql> SELECT *
       FROM performance_schema.setup_instruments
       WHERE NAME = 'transaction';
+-------------+---------+-------+
| NAME        | ENABLED | TIMED |
+-------------+---------+-------+
| transaction | NO      | NO    |
+-------------+---------+-------+
mysql> SELECT *
       FROM performance_schema.setup_consumers
       WHERE NAME LIKE 'events_transactions%';
+----------------------------------+---------+
| NAME                             | ENABLED |
+----------------------------------+---------+
| events_transactions_current      | NO      |
| events_transactions_history      | NO      |
| events_transactions_history_long | NO      |
+----------------------------------+---------+

要在服务器启动时控制事务事件收集，请在my.cnf文件中使用以下行：

Enable:

[mysqld]
performance-schema-instrument='transaction=ON'
performance-schema-consumer-events-transactions-current=ON
performance-schema-consumer-events-transactions-history=ON
performance-schema-consumer-events-transactions-history-long=ON

Disable:

[mysqld]
performance-schema-instrument='transaction=OFF'
performance-schema-consumer-events-transactions-current=OFF
performance-schema-consumer-events-transactions-history=OFF
performance-schema-consumer-events-transactions-history-long=OFF

要在运行时控制事务事件收集，请更新setup_instruments和setup_consumerstable：

Enable:

UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME = 'transaction';

UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME LIKE 'events_transactions%';

Disable:

UPDATE performance_schema.setup_instruments
SET ENABLED = 'NO', TIMED = 'NO'
WHERE NAME = 'transaction';

UPDATE performance_schema.setup_consumers
SET ENABLED = 'NO'
WHERE NAME LIKE 'events_transactions%';

要仅收集特定 Transaction 事件 table 的 Transaction 事件，请启用transaction工具，但仅启用与所需 table 相对应的 Transaction 使用者。

setup_timerstable 包含NAME值为transaction的行，该行指示 Transaction 事件计时的单位。默认单位是NANOSECOND：

mysql> SELECT *
       FROM performance_schema.setup_timers
       WHERE NAME = 'transaction';
+-------------+------------+
| NAME        | TIMER_NAME |
+-------------+------------+
| transaction | NANOSECOND |
+-------------+------------+

要更改计时单位，请修改TIMER_NAME值：

UPDATE performance_schema.setup_timers
SET TIMER_NAME = 'MICROSECOND'
WHERE NAME = 'transaction';

有关配置事件收集的其他信息，请参阅第 25.3 节“性能架构启动配置”和第 25.4 节“性能架构运行时配置”。

Transaction Boundaries

在 MySQL Server 中，事务从以下语句明确开始：

START TRANSACTION | BEGIN | XA START | XA BEGIN

事务也会隐式启动。例如，启用autocommit系统变量时，每个语句的开头将启动一个新事务。

禁用autocommit时，已提交事务后的第一条语句标记新事务的开始。后续语句在提交之前是事务的一部分。

事务显式以以下语句结束：

COMMIT | ROLLBACK | XA COMMIT | XA ROLLBACK

通过执行 DDL 语句，锁定语句和服务器 Management 语句，事务也隐式结束。

在以下讨论中，对START TRANSACTION的引用也适用于BEGIN，XA START和XA BEGIN。类似地，对COMMIT和ROLLBACK的引用分别适用于XA COMMIT和XA ROLLBACK。

性能架构定义事务边界的方式与服务器类似。事务事件的开始和结束与服务器中相应的状态转换非常匹配：

对于显式启动的事务，事务事件在处理START TRANSACTION语句期间开始。
对于隐式启动的事务，在先前的事务结束之后，事务事件从使用事务引擎的第一条语句开始。
对于任何事务，无论是显式还是隐式结束，当服务器在处理COMMIT或ROLLBACK时从活动事务状态过渡出来时，事务事件都会结束。

这种方法有一些细微的含义：

性能架构中的事务事件未完全包含与相应的START TRANSACTION，COMMIT或ROLLBACK语句关联的语句事件。事务事件和这些语句之间的时间重叠很小。
使用非事务引擎的语句对连接的事务状态没有影响。对于隐式事务，事务事件从使用事务引擎的第一条语句开始。这意味着即使在START TRANSACTION之后，也将忽略专门在非事务 table 上运行的语句。

为了说明，请考虑以下情形：

1. SET autocommit = OFF;
2. CREATE TABLE t1 (a INT) ENGINE = InnoDB;
3. START TRANSACTION;                       -- Transaction 1 START
4. INSERT INTO t1 VALUES (1), (2), (3);
5. CREATE TABLE t2 (a INT) ENGINE = MyISAM; -- Transaction 1 COMMIT
                                            -- (implicit; DDL forces commit)
6. INSERT INTO t2 VALUES (1), (2), (3);     -- Update nontransactional table
7. UPDATE t2 SET a = a + 1;                 -- ... and again
8. INSERT INTO t1 VALUES (4), (5), (6);     -- Write to transactional table
                                            -- Transaction 2 START (implicit)
9. COMMIT;                                  -- Transaction 2 COMMIT

从服务器的角度来看，事务 1 在创建 tablet2时结束。事务 2 直到访问事务 table 后才开始，尽管对非事务 table 进行了中间更新。

从性能架构的角度来看，事务 2 在服务器转换为活动事务状态时启动。语句 6 和 7 不包括在事务 2 的边界内，这与服务器将事务写入二进制日志的方式一致。

Transaction Instrumentation

定义 Transaction 的三个属性：

访问模式(只读，读写)
隔离级别(SERIALIZABLE，REPEATABLE READ等)
隐式(启用autocommit)或显式(禁用autocommit)

为了降低事务工具的复杂性并确保所收集的事务数据提供完整的有意义的结果，所有事务均独立于访问模式，隔离级别或自动提交模式进行工具检测。

要有选择地检查事务历史记录，请使用事务事件 table 中的属性列：ACCESS_MODE，ISOLATION_LEVEL和AUTOCOMMIT。

可以通过多种方式减少事务检测的成本，例如根据用户，帐户，主机或线程(Client 端连接)启用或禁用事务检测。

Transaction 和嵌套事件

事务事件的父事件是启动事务的事件。对于显式启动的事务，这包括START TRANSACTION和承诺和链语句。对于隐式启动的事务，它是在前一个事务结束之后使用事务引擎的第一条语句。

通常，事务是事务期间发起的所有事件(包括明确结束事务的语句，例如COMMIT和ROLLBACK)的顶级父级。异常是隐式结束事务的语句，例如 DDL 语句，在这种情况下，必须在执行新语句之前提交当前事务。

事务和存储的程序

事务和存储的程序事件的相关性如下：

Stored Procedures

存储过程独立于事务运行。可以在事务内启动存储过程，并且可以从存储过程内启动或结束事务。如果从事务内调用，则存储过程可以执行强制执行父事务的语句，然后启动新事务。

如果存储过程在事务内启动，则该事务是该存储过程事件的父级。

如果事务由存储过程启动，则该存储过程是事务事件的父级。

Stored Functions

存储函数受到限制，不能导致显式或隐式的提交或回滚。存储的函数事件可以驻留在父事务事件中。

Triggers

触发器作为访问与其关联的 table 的语句的一部分进行激活，因此触发器事件的父级始终是激活它的语句。

触发器不能发出导致事务的显式或隐式提交或回滚的语句。

Scheduled Events

计划事件主体中的语句执行在新 Connecting 进行。在父事务中计划事件的嵌套不适用。

Transaction 和保存点

保存点语句记录为单独的语句事件。事务事件包括在事务期间发出的SAVEPOINT，回滚到保存点和RELEASE SAVEPOINT语句的单独计数器。

Transaction 和错误

事务中发生的错误和警告记录在语句事件中，而不记录在相应的事务事件中。这包括特定于事务的错误和警告，例如非事务 table 上的回滚或 GTID 一致性错误。

Name	MySql 中文文档
Version
Language
Badge
Last Updated	2021-07-03T12:24:35