[+/-]
To avoid confusion, for the purposes of this discussion we define the term “ib-file set” to mean the set of operating system files that InnoDB manages as a unit. The ib-file set includes the following files:
          The system tablespace (one or more ibdata
          files) that contain internal system information (including
          internal catalogs and undo information) and may include user
          data and indexes.
        
          Zero or more single-table tablespaces (also called “file
          per table” files, named *.ibd
          files).
        
          (Usually two) InnoDB log files
          (ib_logfile0 and
          ib_logfile1), used for crash recovery and
          in backups.
        
      This collection of files is transactionally consistent, and
      recoverable as a unit. An “ib-file set” specifically
      does not include the related MySQL .frm files
      that contain meta data about InnoDB tables. The
      .frm files are created and managed exclusively
      by MySQL, and can sometimes get out of sync with the internal
      meta data in InnoDB.
    
Instead of “ib-file set”, we might call such a collection a “database”. However, MySQL uses the word “database” to mean a logical collection of tables, what other systems term a “schema” or “catalog”. Given MySQL terminology, multiple tables (even from more than one database) can be stored in a single “ib-file set”.
The InnoDB storage engine incorporates several checks to guard against the possible crashes and data corruptions that might occur if you use an ib-file set in a file format that is not supported by the software release in use. These checks take place when the server is started, and when you first access a table. This section describes these checks, how you can control them, and error and warning conditions that may arise.
This is the User’s Guide for InnoDB storage engine 1.1 for MySQL 5.5, generated on 2010-04-13 (revision: 19994) .

