29.12.7 Performance Schema 交易表
性能Schema对事务进行了instrumentation。事件层次结构中,等待事件嵌套在阶段事件中,阶段事件嵌套在语句事件中,语句事件嵌套在事务事件中。
这些表格存储事务事件:
-
events_transactions_current
:当前事务事件每个线程。 -
events_transactions_history
:最近结束的事务事件每个线程。 -
events_transactions_history_long
:最近结束的事务事件全球(跨越所有线程)。
以下部分描述了事务事件表。还有一些汇总表,聚合了事务事件信息;见Section 29.12.20.5,“Transaction Summary Tables”。
关于三个事务事件表之间关系的更多信息,请见Section 29.9,“Performance Schema Tables for Current and Historical Events”。
控制是否收集事务事件,设置相关的工具和消费者状态:
事务
工具和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
控制事务事件收集在运行时,更新设置工具
和设置消费者
表:
-
启用:
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%';
只收集特定事务事件表的事件,启用
事务
工具,但只启用与所需表对应的事务消费者。
关于事件收集配置的更多信息,请参阅第29.3节,“性能_schema启动配置”和第29.4节,“性能_schema运行配置”。
在 MySQL 服务器中,事务以以下语句开始:
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
,分别。
性能Schema定义了事务边界与服务器类似。事务事件的开始和结束与服务器的相应状态转换相匹配:
-
对于明确开始的事务,事务事件在处理
START TRANSACTION
语句时启动。 -
对于隐式开始的事务,事务事件在使用事务引擎的第一个语句后启动,这个语句是之前事务结束后的语句。
这有微妙的含义:
-
性能Schema中的事务事件不完全包括与相应
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
从服务器的角度,事务1在创建表t2
时结束。事务2直到访问事务表才开始,尽管中间有非事务表的更新。
从性能_schema的角度,事务2从服务器进入活动事务状态时开始。语句6和7不在事务2的边界内,这与服务器将事务写入二进制日志的方式一致。
三个属性定义事务:
-
访问模式(只读、读写)
-
隔离级别(
SERIALIZABLE
、REPEATABLE READ
等) -
隐式(
autocommit
启用)或显式(autocommit
禁用)
为了简化事务 Instrumentation和确保收集的事务数据提供完整、有意义的结果,所有事务都独立地 Instrumented,不考虑访问模式、隔离级别或自动提交模式。
要选择性地查看事务历史,请使用事务事件表中的属性列:ACCESS_MODE
、ISOLATION_LEVEL
和AUTOCOMMIT
。
事务 Instrumentation 的成本可以通过多种方式减少,例如根据用户、帐户、主机或线程(客户端连接)启用或禁用事务 Instrumentation。
事务事件的父是引发事务的事件。对于明确开始的事务,这包括START TRANSACTION
和COMMIT AND CHAIN
语句。对于隐式开始的事务,它是使用事务引擎的第一个语句,自上一个事务结束后。
一般来说,事务是所有在事务中引发的事件的顶级父,包括语句,如COMMIT
和ROLLBACK
。除此之外,语句隐式结束事务,如DDL语句,在这种情况下,当前事务必须提交,然后执行新语句。
事务和存储程序事件之间存在以下关系:
-
存储程序
存储程序独立于事务。存储程序可以在事务中启动,事务也可以在存储程序中启动或结束。如果从事务中调用存储程序,存储程序可以执行语句,强制提交父事务,然后启动新事务。
如果存储程序在事务中启动,那么该事务是存储程序事件的父。
如果事务由存储过程启动,存储过程是事务事件的父级。
-
存储函数
存储函数不能导致明确或隐式的事务提交或回滚。存储函数事件可以在父事务事件中驻留。
-
触发器
触发器在访问关联表的语句中激活,因此触发器事件的父级总是激活它的语句。
触发器不能发出导致事务明确或隐式提交或回滚的语句。
-
计划事件
计划事件的语句体在新连接中执行。计划事件不能嵌套在父事务中。
保存点语句被记录为单独的语句事件。事务事件包括单独的计数器,对于SAVEPOINT
、ROLLBACK TO SAVEPOINT
和RELEASE SAVEPOINT
在事务中发布的语句。
在事务中发生的错误和警告记录在语句事件中,而不是对应的事务事件中。这包括事务特定的错误和警告,例如非事务表的回滚或GTID一致性错误。