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 instrument，但僅啟用對應所需資料表的交易 consumer。

關於設定事件收集的更多資訊，請參閱第 29.3 節，「Performance Schema 啟動設定」，以及第 29.4 節，「Performance Schema 執行階段設定」。

交易邊界

在 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。

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 的邊界內，這與伺服器將交易寫入二進位記錄的方式一致。

交易檢測

三個屬性定義交易

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

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

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

交易和巢狀事件

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

一般來說，交易是交易期間啟動的所有事件的最高層父項，包括明確結束交易的陳述式，例如 COMMIT 和 ROLLBACK。例外情況是隱含結束交易的陳述式，例如 DDL 陳述式，在這種情況下，必須先提交目前的交易，然後才能執行新的陳述式。

交易和預存程式

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

交易和儲存點

儲存點陳述式會記錄為單獨的陳述式事件。交易事件包含交易期間發出的 SAVEPOINT、ROLLBACK TO SAVEPOINT 和 RELEASE SAVEPOINT 陳述式的個別計數器。

交易和錯誤

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