MySQL Manual
7 MySQL Table Types
- 7.5
InnoDBTables- 7.5.1 InnoDB Tables Overview
- 7.5.2 InnoDB in MySQL Version 3.23
- 7.5.3 InnoDB Startup Options
- 7.5.4 Creating InnoDB Tablespace
- 7.5.5 Creating InnoDB Tables
- 7.5.6 Adding and Removing InnoDB Data and Log Files
- 7.5.7 Backing up and Recovering an InnoDB Database
- 7.5.8 Moving an InnoDB Database to Another Machine
- 7.5.9 InnoDB Transaction Model
- 7.5.10 Implementation of Multi-versioning
- 7.5.11 Table and Index Structures
- 7.5.12 File Space Management and Disk I/O
- 7.5.13 Error Handling
- 7.5.14 Restrictions on InnoDB Tables
- 7.5.15 InnoDB Change History
- 7.5.16
InnoDBContact Information
7.5.10 Implementation of Multi-versioning
Since InnoDB is a multi-versioned database, it must keep information of old versions of rows in the tablespace. This information is stored in a data structure we call a rollback segment after an analogous data structure in Oracle.
InnoDB internally adds two fields to each row stored in the database. A 6-byte field tells the transaction identifier for the last transaction which inserted or updated the row. Also a deletion is internally treated as an update where a special bit in the row is set to mark it as deleted. Each row also contains a 7-byte field called the roll pointer. The roll pointer points to an undo log record written to the rollback segment. If the row was updated, then the undo log record contains the information necessary to rebuild the content of the row before it was updated.
InnoDB uses the information in the rollback segment to perform the undo operations needed in a transaction rollback. It also uses the information to build earlier versions of a row for a consistent read.
Undo logs in the rollback segment are divided into insert and update undo logs. Insert undo logs are only needed in transaction rollback and can be discarded as soon as the transaction commits. Update undo logs are used also in consistent reads, and they can be discarded only after there is no transaction present for which InnoDB has assigned a snapshot that in a consistent read could need the information in the update undo log to build an earlier version of a database row.
You must remember to commit your transactions regularly, also those transactions which only issue consistent reads. Otherwise InnoDB cannot discard data from the update undo logs, and the rollback segment may grow too big, filling up your tablespace.
The physical size of an undo log record in the rollback segment is typically smaller than the corresponding inserted or updated row. You can use this information to calculate the space need for your rollback segment.
In our multi-versioning scheme a row is not physically removed from the database immediately when you delete it with an SQL statement. Only when InnoDB can discard the update undo log record written for the deletion, it can also physically remove the corresponding row and its index records from the database. This removal operation is called a purge, and it is quite fast, usually taking the same order of time as the SQL statement which did the deletion.
