Performance Schema 會檢測交易。在事件階層中，等待事件會巢狀於階段事件內，階段事件會巢狀於陳述式事件內，陳述式事件會巢狀於交易事件內。

這些表格會儲存交易事件

以下章節說明交易事件表格。還有摘要表格會彙總交易事件的相關資訊；請參閱章節 29.12.20.5，「交易摘要表格」。

如需關於三個交易事件表格之間關係的詳細資訊，請參閱章節 29.9，「Performance Schema 用於目前和歷史事件的表格」。

設定交易事件收集

若要控制是否收集交易事件，請設定相關工具和消費者的狀態

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 檔案中使用如下的程式碼行：

若要在執行階段控制交易事件收集，請更新 setup_instruments 和 setup_consumers 表格。

若只要收集特定交易事件表格的交易事件，請啟用 transaction 儀器，但僅啟用對應到所需表格的交易消費者。

關於設定事件收集的更多資訊，請參閱 第 29.3 節，「Performance Schema 啟動設定」和 第 29.4 節，「Performance 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。

Performance Schema 定義的交易邊界與伺服器的定義類似。交易事件的開始和結束與伺服器中的相應狀態轉換密切匹配。

這種方法有一些微妙的含義：

為了說明，請考慮以下情境：

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 不會開始，儘管在中間對非交易表格進行了更新。

從 Performance Schema 的角度來看，當伺服器轉換為使用中交易狀態時，交易 2 開始。語句 6 和 7 未包含在交易 2 的邊界內，這與伺服器將交易寫入二進位記錄的方式一致。

交易儀器

有三個屬性定義交易：

為了降低交易儀器的複雜性，並確保收集的交易資料提供完整、有意義的結果，所有交易都會獨立於存取模式、隔離級別或自動提交模式進行儀器化。

若要選擇性地檢查交易歷史記錄，請使用交易事件表格中的屬性欄：ACCESS_MODE、ISOLATION_LEVEL 和 AUTOCOMMIT。

可以透過各種方式降低交易儀器的成本，例如根據使用者、帳戶、主機或執行緒（用戶端連線）啟用或停用交易儀器。

交易和巢狀事件

交易事件的父系是啟動該交易的事件。對於明確開始的交易，這包含 START TRANSACTION 和 COMMIT AND CHAIN 語句。對於隱含開始的交易，它是先前交易結束後，使用交易引擎的第一個語句。

一般而言，交易是交易期間啟動的所有事件的頂層父系，包括明確結束交易的語句，例如 COMMIT 和 ROLLBACK。例外情況是隱含結束交易的語句，例如 DDL 語句，在這種情況下，必須在執行新語句之前提交目前的交易。

交易和預存程式

交易和預存程式事件的關係如下：

交易和儲存點

儲存點語句會記錄為個別的語句事件。交易事件包含在交易期間發出的 SAVEPOINT、ROLLBACK TO SAVEPOINT 和 RELEASE SAVEPOINT 語句的個別計數器。

交易和錯誤

在交易中發生的錯誤和警告會記錄在語句事件中，而不是在對應的交易事件中。這包括特定於交易的錯誤和警告，例如在非交易表格上回滾或 GTID 一致性錯誤。