MySQL 5.1 Reference Manual :: 14 Storage Engines and Table Types :: 14.5 The InnoDB Storage Engine :: 14.5.10 InnoDB Transaction Model and Locking
Section Navigation [Toggle]
- 14.5 The InnoDB Storage Engine
- 14.5.1 InnoDB Overview
- 14.5.2 InnoDB Contact Information
- 14.5.3 InnoDB Configuration
- 14.5.4 InnoDB Startup Options and System Variables
- 14.5.5 Creating the InnoDB Tablespace
- 14.5.6 Creating and Using InnoDB Tables
- 14.5.7 Adding and Removing InnoDB Data and Log Files
- 14.5.8 Backing Up and Recovering an InnoDB Database
- 14.5.9 Moving an InnoDB Database to Another Machine
- 14.5.10 InnoDB Transaction Model and Locking
- 14.5.10.1 InnoDB Lock Modes
- 14.5.10.2 InnoDB and AUTOCOMMIT
- 14.5.10.3 InnoDB and TRANSACTION ISOLATION LEVEL
- 14.5.10.4 Consistent Non-Locking Read
- 14.5.10.5 SELECT ... FOR UPDATE and SELECT ... LOCK IN SHARE MODE Locking Reads
- 14.5.10.6 Next-Key Locking: Avoiding the Phantom Problem
- 14.5.10.7 An Example of Consistent Read in InnoDB
- 14.5.10.8 Locks Set by Different SQL Statements in InnoDB
- 14.5.10.9 Implicit Transaction Commit and Rollback
- 14.5.10.10 Deadlock Detection and Rollback
- 14.5.10.11 How to Cope with Deadlocks
- 14.5.11 InnoDB Performance Tuning Tips
- 14.5.12 Implementation of Multi-Versioning
- 14.5.13 InnoDB Table and Index Structures
- 14.5.14 InnoDB File Space Management and Disk I/O
- 14.5.15 InnoDB Error Handling
- 14.5.16 Restrictions on InnoDB Tables
- 14.5.17 InnoDB Troubleshooting
- 14.5.10.1.
InnoDBLock Modes - 14.5.10.2.
InnoDBandAUTOCOMMIT - 14.5.10.3.
InnoDBandTRANSACTION ISOLATION LEVEL - 14.5.10.4. Consistent Non-Locking Read
- 14.5.10.5.
SELECT ... FOR UPDATEandSELECT ... LOCK IN SHARE MODELocking Reads - 14.5.10.6. Next-Key Locking: Avoiding the Phantom Problem
- 14.5.10.7. An Example of Consistent Read in
InnoDB - 14.5.10.8. Locks Set by Different SQL Statements in
InnoDB - 14.5.10.9. Implicit Transaction Commit and Rollback
- 14.5.10.10. Deadlock Detection and Rollback
- 14.5.10.11. How to Cope with Deadlocks
In the InnoDB transaction model, the goal is to
combine the best properties of a multi-versioning database with
traditional two-phase locking. InnoDB does
locking on the row level and runs queries as non-locking
consistent reads by default, in the style of Oracle. The lock
table in InnoDB is stored so space-efficiently
that lock escalation is not needed: Typically several users are
allowed to lock every row in the database, or any random subset of
the rows, without InnoDB running out of memory.
User Comments
Add your own comment.