Understanding InnoDB Transaction Types and Allocation Process in MySQL 8.0.32

Author: Cao Shengchun, iKangSheng technical expert, author of the public account "Yi Shu Yi Xi", focusing on MySQL and OceanBase source code analysis.

Source: iKangSheng Open Source Community, original content, please contact for reuse.

Table of Contents

1. User Transactions and Internal Transactions

2. Allocating Transaction Objects

3. Additional Initialization Work

4. Adding Transaction to List

5. Summary

1. User Transactions and Internal Transactions

InnoDB executes all read/write operations within a transaction. There are two ways to start a transaction:

Manual: using BEGIN or START TRANSACTION and their variants.

Automatic: executing a single SQL statement causes InnoDB to start a transaction automatically and commit it after the statement finishes.

Both methods create user transactions , which run user SQL statements.

InnoDB sometimes runs its own SQL statements, called internal SQL , which must also run inside a transaction, termed an internal transaction .

Typical scenarios for internal transactions include:

Recovering uncommitted or partially committed transactions after a server restart.

Background threads (e.g., ib_dict_stats ) updating statistics tables via internal SQL.

DDL execution that logs information into mysql.innodb_ddl_log using internal transactions.

2. Allocating Transaction Objects

InnoDB manages transaction objects with a transaction pool and a pool manager.

Before any transaction (user or internal) can start, the pool manager must allocate a transaction object from a pool’s transaction queue.

The allocation process scans pools in order:

If the current pool’s queue has a free object, allocate it.

Otherwise, check for uninitialized memory chunks in the pool; if present, initialize them, fill the queue, and allocate.

If no free objects or memory remain, move to the next pool.

If all existing pools are exhausted, create a new pool, initialize it, and allocate from its queue.

3. Additional Initialization Work

The allocated transaction object starts with default settings. InnoDB then re‑initializes several fields:

trx->state is set to TRX_STATE_NOT_STARTED , indicating the transaction has not begun.

trx->in_innodb receives the TRX_FORCE_ROLLBACK_DISABLE flag to prevent forced rollback by other threads.

trx->lock.autoinc_locks is allocated to hold auto‑increment lock structures for generating auto‑increment values.

Example output of SHOW ENGINE INNODB STATUS shows a transaction with the state "not started", derived from TRX_STATE_NOT_STARTED :

LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 281480261177256, not started
0 lock struct(s), heap size 1192, 0 row lock(s)

4. Adding Transaction to List

After allocating a transaction object for a user transaction, it must be inserted at the head of the user‑transaction list:

UT_LIST_ADD_FIRST(trx_sys->mysql_trx_list, trx);

This list ( trx_sys->mysql_trx_list ) records only user transactions. Internal transactions are placed in a different list, which will be introduced later.

5. Summary

InnoDB categorizes transactions into user and internal types. When allocating a transaction object, the process follows:

First, try to allocate from the pool’s transaction queue.

If the queue is empty, initialize remaining memory chunks in the pool and allocate from them.

If all pools lack free memory, create a new pool and allocate from it.

Question: Why doesn’t InnoDB add internal transactions to trx_sys->mysql_trx_list ? Feel free to comment.

Next Issue Preview: After this preparation, we will finally start InnoDB transactions.