• 首页
  • css3教程
  • html5教程
  • jQuery手册
  • php7教程
  • MySQL手册
  • apache手册
  • 位置: MySQL8中文手册 -> MySQL性能模式

    性能架构事务表

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

    这些表存储事务事件:

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

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

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

    配置事务事件整理

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

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

    transaction仪器与events_transactions_currentevents_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_instrumentssetup_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也适用于BEGINXA STARTXA BEGIN。同样,分别引用COMMITROLLBACK适用于XA COMMITXA ROLLBACK

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

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

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

    • 在Performance模式,交易事件不完全包括与对应的相关联的声明事件START TRANSACTIONCOMMITROLLBACK语句。事务事件和这些语句之间的时间重叠很小。
    • 使用非事务引擎的语句对连接的事务状态没有影响。对于隐式事务,事务事件从使用事务引擎的第一条语句开始。这意味着,仅在非事务处理表上运行的语句将被忽略,即使遵循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的边界内,这与服务器将事务写入二进制日志的方式一致。

    交易工具

    定义交易的三个属性:

    • 访问模式(只读,读写)
    • 隔离级别(SERIALIZABLEREPEATABLE READ等)
    • 隐式(autocommit启用)或显式(autocommit禁用)

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

    要选择性地检查交易记录,在交易事件表使用的属性列:ACCESS_MODEISOLATION_LEVEL,和AUTOCOMMIT

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

    交易和嵌套事件

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

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

    交易和存储程序

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

    • 存储过程

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

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

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

    • 存储的功能

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

    • 扳机

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

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

    • 预定活动

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

    交易和保存点

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

    交易和错误

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