In raw MySQL binlogs, a single logical transaction (e.g. updating an order, deducting inventory, and inserting an audit log) is written across dozens of individual low-level events: QUERY (BEGIN), TABLE_MAP, UPDATE_ROWS, WRITE_ROWS, and finally an XID (or COMMIT) event.
How MySQL Groups Transactions
Scanning binlogs linearly makes it nearly impossible to tell which row changes belonged to which transaction. Binsight reconstructs logical transactions automatically by tracking:
- GTID (Global Transaction Identifier): For clusters running with GTID mode enabled, every transaction is grouped by its unique UUID + sequence number.
- Anonymous Transactions (XID): For non-GTID setups, Binsight groups all events starting from
BEGINup to the terminatingXID_EVENT.
XID & Two-Phase Commit Boundaries
The XID event marks the exact instant a transaction achieved two-phase commit durability on the InnoDB storage engine. Binsight correlates all table maps and row mutations that shared the same internal transaction ID:
Flat View vs. Grouped View
In the Binsight web console, press the t key to instantly toggle between:
- Flat View: Shows every individual raw binlog event sequentially, ideal for checking protocol-level markers like
FORMAT_DESCRIPTION,ROTATE, andHEARTBEAT. - Grouped View: Collapses all events into expandable transaction cards showing total rows affected, execution latency, and table distribution.
Identifying Rolled-Back Transactions
When an explicit ROLLBACK occurs in InnoDB, transactional row changes are not written to the binlog. However, changes to non-transactional tables (such as MyISAM or temporary tables) modified within a rolled-back transaction are recorded. Binsight flags these anomalies with a warning pill.