When autocommit  is disabled, the first statement following a committed transaction marks the start of a new transaction. Subsequent statements are part of the transaction until it is committed. 

Transactions explicitly end with these statements: 

COMMIT | ROLLBACK | XA COMMIT | XA ROLLBACK 

Transactions also end implicitly, by execution of DDL statements, locking statements, and server administration statements. 

In the following discussion, references to START TRANSACTION  also apply to BEGIN , XA START , and XA BEGIN . Similarly, references to COMMIT  and ROLLBACK  apply to XA COMMIT  and XA ROLLBACK , respectively. 

The Performance Schema defines transaction boundaries similarly to that of the server. The start and end of a transaction event closely match the corresponding state transitions in the server: 

•For an explicitly started transaction, the transaction event starts during processing of the START TRANSACTION  statement. 

•For an implicitly started transaction, the transaction event starts on the first statement that uses a transactional engine after the previous transaction has ended. 

•For any transaction, whether explicitly or implicitly ended, the transaction event ends when the server transitions out of the active transaction state during the processing of COMMIT  or ROLLBACK . 

There are subtle implications to this approach: 

•Transaction events in the Performance Schema do not fully include the statement events associated with the corresponding START TRANSACTION , COMMIT , or ROLLBACK  statements. There is a trivial amount of timing overlap between the transaction event and these statements. 

•Statements that work with nontransactional engines have no effect on the transaction state of the connection. For implicit transactions, the transaction event begins with the first statement that uses a transactional engine. This means that statements operating exclusively on nontransactional tables are ignored, even following START TRANSACTION . 

To illustrate, consider the following scenario: 

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 

From the perspective of the server, Transaction 1 ends when table t2  is created. Transaction 2 does not start until a transactional table is accessed, despite the intervening updates to nontransactional tables. 

From the perspective of the Performance Schema, Transaction 2 starts when the server transitions into an active transaction state. Statements 6 and 7 are not included within the boundaries of Transaction 2, which is consistent with how the server writes transactions to the binary log. 

## Transaction Instrumentation 

Three attributes define transactions: 

