The file ibdata1 is the system tablespace for the InnoDB infrastructure.
It contains several classes for information vital for InnoDB
- Table Data Pages
- Table Index Pages
- Data Dictionary
- MVCC Control Data
- Undo Space
- Rollback Segments
- Double Write Buffer (Pages Written in the Background to avoid OS caching)
- Insert Buffer (Changes to Secondary Indexes)
Click Here to see a Pictorial Representation
You can divorce Data and Index Pages from ibdata1 by enabling innodb_file_per_table. This will cause any newly created InnoDB table to store data and index pages in an external
- datadir is /var/lib/mysql
CREATE TABLE mydb.mytable (...) ENGINE=InnoDB;, creates
- innodb_file_per_table disabled, Data/Index Pages Stored in
- innodb_file_per_table enbled, Data/Index Pages Stored in ibdata1
No matter where the InnoDB table is stored, InnoDB's functionality requires looking for table metadata and storing and retrieving MVCC info to support ACID compliance and Transaction Isolation.
Here are my past articles on separating table data and indexes from ibdata1
iblog files (a.k.a.
If you want to know what the
ib_logfile1 are for, they are the InnoDB Redo Logs. They should never be erased or resized until a full normal shutdown of mysqld has taken place. If mysqld ever crashes, just start up mysqld. It will read across
ib_logfile1 to check for any data changes that were not posted to the the double write buffer in
ibdata1. It will replay (redo) those changes. Once they are replayed and stored, mysqld becomes ready for new DB Connections.