The events_transactions_current
table contains current transaction events. The table stores
one row per thread showing the current status of the thread's
most recent monitored transaction event, so there is no system
variable for configuring the table size. For example:
mysql> SELECT *
FROM performance_schema.events_transactions_current LIMIT 1\G
*************************** 1. row ***************************
THREAD_ID: 26
EVENT_ID: 7
END_EVENT_ID: NULL
EVENT_NAME: transaction
STATE: ACTIVE
TRX_ID: NULL
GTID: 3E11FA47-71CA-11E1-9E33-C80AA9429562:56
XID: NULL
XA_STATE: NULL
SOURCE: transaction.cc:150
TIMER_START: 420833537900000
TIMER_END: NULL
TIMER_WAIT: NULL
ACCESS_MODE: READ WRITE
ISOLATION_LEVEL: REPEATABLE READ
AUTOCOMMIT: NO
NUMBER_OF_SAVEPOINTS: 0
NUMBER_OF_ROLLBACK_TO_SAVEPOINT: 0
NUMBER_OF_RELEASE_SAVEPOINT: 0
OBJECT_INSTANCE_BEGIN: NULL
NESTING_EVENT_ID: 6
NESTING_EVENT_TYPE: STATEMENT
Of the tables that contain transaction event rows,
events_transactions_current is
the most fundamental. Other tables that contain transaction
event rows are logically derived from the current events. For
example, the
events_transactions_history and
events_transactions_history_long
tables are collections of the most recent transaction events
that have ended, up to a maximum number of rows per thread and
globally across all threads, respectively.
For more information about the relationship between the three transaction event tables, see Section 25.9, “Performance Schema Tables for Current and Historical Events”.
For information about configuring whether to collect transaction events, see Section 25.12.7, “Performance Schema Transaction Tables”.
The events_transactions_current
table has these columns:
THREAD_ID,EVENT_IDThe thread associated with the event and the thread current event number when the event starts. The
THREAD_IDandEVENT_IDvalues taken together uniquely identify the row. No two rows have the same pair of values.END_EVENT_IDThis column is set to
NULLwhen the event starts and updated to the thread current event number when the event ends.EVENT_NAMEThe name of the instrument from which the event was collected. This is a
NAMEvalue from thesetup_instrumentstable. Instrument names may have multiple parts and form a hierarchy, as discussed in Section 25.6, “Performance Schema Instrument Naming Conventions”.STATEThe current transaction state. The value is
ACTIVE(afterSTART TRANSACTIONorBEGIN),COMMITTED(afterCOMMIT), orROLLED BACK(afterROLLBACK).TRX_IDUnused.
GTIDThe GTID column contains the value of
gtid_next, which can be one ofANONYMOUS,AUTOMATIC, or a GTID using the formatUUID:NUMBER. For transactions that usegtid_next=AUTOMATIC, which is all normal client transactions, the GTID column changes when the transaction commits and the actual GTID is assigned. Ifgtid_modeis eitherONorON_PERMISSIVE, the GTID column changes to the transaction's GTID. Ifgtid_modeis eitherOFForOFF_PERMISSIVE, the GTID column changes toANONYMOUS.XID_FORMAT_ID,XID_GTRID, andXID_BQUALThe elements of the XA transaction identifier. They have the format described in Section 13.3.7.1, “XA Transaction SQL Statements”.
XA_STATEThe state of the XA transaction. The value is
ACTIVE(afterXA START),IDLE(afterXA END),PREPARED(afterXA PREPARE),ROLLED BACK(afterXA ROLLBACK), orCOMMITTED(afterXA COMMIT).On a replica, the same XA transaction can appear in the
events_transactions_currenttable with different states on different threads. This is because immediately after the XA transaction is prepared, it is detached from the replication applier thread, and can be committed or rolled back by any thread on the replica. Theevents_transactions_currenttable displays the current status of the most recent monitored transaction event on the thread, and does not update this status when the thread is idle. So the XA transaction can still be displayed in thePREPAREDstate for the original applier thread, after it has been processed by another thread. To positively identify XA transactions that are still in thePREPAREDstate and need to be recovered, use theXA RECOVERstatement rather than the Performance Schema transaction tables.SOURCEThe name of the source file containing the instrumented code that produced the event and the line number in the file at which the instrumentation occurs. This enables you to check the source to determine exactly what code is involved.
TIMER_START,TIMER_END,TIMER_WAITTiming information for the event. The unit for these values is picoseconds (trillionths of a second). The
TIMER_STARTandTIMER_ENDvalues indicate when event timing started and ended.TIMER_WAITis the event elapsed time (duration).If an event has not finished,
TIMER_ENDis the current timer value andTIMER_WAITis the time elapsed so far (TIMER_END−TIMER_START).If an event is produced from an instrument that has
TIMED = NO, timing information is not collected, andTIMER_START,TIMER_END, andTIMER_WAITare allNULL.For discussion of picoseconds as the unit for event times and factors that affect time values, see Section 25.4.1, “Performance Schema Event Timing”.
ACCESS_MODEThe transaction access mode. The value is
READ WRITEorREAD ONLY.ISOLATION_LEVELThe transaction isolation level. The value is
REPEATABLE READ,READ COMMITTED,READ UNCOMMITTED, orSERIALIZABLE.AUTOCOMMITWhether autcommit mode was enabled when the transaction started.
NUMBER_OF_SAVEPOINTS,NUMBER_OF_ROLLBACK_TO_SAVEPOINT,NUMBER_OF_RELEASE_SAVEPOINTThe number of
SAVEPOINT,ROLLBACK TO SAVEPOINT, andRELEASE SAVEPOINTstatements issued during the transaction.OBJECT_INSTANCE_BEGINUnused.
NESTING_EVENT_IDThe
EVENT_IDvalue of the event within which this event is nested.NESTING_EVENT_TYPEThe nesting event type. The value is
TRANSACTION,STATEMENT,STAGE, orWAIT. (TRANSACTIONdoes not appear because transactions cannot be nested.)
TRUNCATE TABLE is permitted for
the events_transactions_current
table. It removes the rows.