性能架构事务表

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

这些表存储事务事件：

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

以下各节描述了事务事件表。也有汇总表，汇总有关交易事件的信息。请参见“事务摘要表”。

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

配置事务事件整理

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

• 该setup_instruments表包含一个名为的工具transaction。使用此工具可以启用或禁用单个交易事件类的收集。
• 该setup_consumers表包含具有与当前和历史事务事件表名称对应的名称的使用者值。使用这些使用者来筛选事务事件的集合。

该transaction仪器与events_transactions_current和events_transactions_history交易的消费者是默认启用的：

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

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

• 启用：

  [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
  

• 禁用：

  [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_consumers表：

• 启用：

  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%';
  

• 禁用：

  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工具，但仅启用与所需表相对应的交易使用者。

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

交易边界

在MySQL Server中，交易明确地从以下语句开始：

START TRANSACTION | BEGIN | XA START | XA BEGIN

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

如果autocommit禁用，则已提交事务后的第一条语句将标记新事务的开始。在提交之前，后续语句将成为事务的一部分。

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

COMMIT | ROLLBACK | XA COMMIT | XA ROLLBACK

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

在下面的讨论中，提及START TRANSACTION也适用于BEGIN，XA START和XA BEGIN。同样，分别引用COMMIT和ROLLBACK适用于XA COMMIT和XA ROLLBACK。

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

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

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

• 在Performance模式，交易事件不完全包括与对应的相关联的声明事件START TRANSACTION，COMMIT或ROLLBACK语句。事务事件和这些语句之间的时间重叠很小。
• 使用非事务引擎的语句对连接的事务状态没有影响。对于隐式事务，事务事件从使用事务引擎的第一条语句开始。这意味着，仅在非事务处理表上运行的语句将被忽略，即使遵循START TRANSACTION。

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

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

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

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

交易工具

定义交易的三个属性：

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

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

要选择性地检查交易记录，在交易事件表使用的属性列：ACCESS_MODE，ISOLATION_LEVEL，和AUTOCOMMIT。

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

交易和嵌套事件

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

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

交易和存储程序

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

• 存储过程

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

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

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

• 存储的功能

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

• 扳机

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

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

• 预定活动

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

交易和保存点

保存点语句记录为单独的语句事件。交易活动包括独立的计数器SAVEPOINT，ROLLBACK TO SAVEPOINT以及RELEASE SAVEPOINT在交易期间发表的声明。

交易和错误

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