By default, all InnoDB tables and indexes are
stored in the system
tablespace. As an alternative, you can store each
InnoDB table and associated indexes in its own
data file. This feature is called “file-per-table
tablespaces” because each table has its own tablespace, and
each tablespace has its own
.ibd data
file. This feature is controlled by the
innodb_file_per_table
configuration option.
You can reclaim disk space when truncating or dropping a table
stored in a file-per-table tablepace. Truncating or dropping
tables stored in the shared
system
tablespace creates free space internally in the system
tablespace data files (ibdata
files) which can only be used for new
InnoDB data.
Similarly, a table-copying ALTER
TABLE operation on table that resides in a shared
tablespace can increase the amount of space used by the
tablespace. Such operations may require as much additional
space as the data in the table plus indexes. The additional
space required for the table-copying
ALTER TABLE operation is not
released back to the operating system as it is for
file-per-table tablespaces.
The TRUNCATE TABLE operation is
faster when run on tables stored in file-per-table tablepaces.
You can store specific tables on separate storage devices, for I/O optimization, space management, or backup purposes.
You can run OPTIMIZE TABLE to
compact or recreate a file-per-table tablespace. When you run
an OPTIMIZE TABLE,
InnoDB creates a new
.ibd file with a temporary name, using
only the space required to store actual data. When the
optimization is complete, InnoDB removes
the old .ibd file and replaces it with
the new one. If the previous .ibd file
grew significantly but the actual data only accounted for a
portion of its size, running OPTIMIZE
TABLE can reclaim the unused space.
You can move individual InnoDB tables
rather than entire databases.
Tables created in file-per-table tablespaces use the
Barracuda file format.
The Barracuda file format enables features such as
compressed
and dynamic row
formats. Tables created in the system tablespace cannot use
these features. To take advantage of these features for an
existing table, enable the
innodb_file_per_table setting
and run ALTER TABLE to place the table in a file-per-table
tablespace. Before converting tables, refer to
Section 14.11.5, “Converting Tables from MyISAM to InnoDB”.
t
ENGINE=INNODB
You can enable more efficient storage for tables with large
BLOB or TEXT columns
using the dynamic row
format.
File-per-table tablespaces may improve chances for a successful recovery and save time when a corruption occurs, when a server cannot be restarted, or when backup and binary logs are unavailable.
You can back up or restore individual tables quickly using the
MySQL Enterprise Backup product, without interrupting the use
of other InnoDB tables. This is beneficial
if you have tables that require backup less frequently or on a
different backup schedule. See
Partial Backup and Restore Options for details.
File-per-table tablespaces are convenient for per-table status reporting when copying or backing up tables.
You can monitor table size at a file system level, without accessing MySQL.
Common Linux file systems do not permit concurrent writes to a
single file when
innodb_flush_method is set to
O_DIRECT. As a result, there are possible
performance improvements when using
innodb_file_per_table in
conjunction with
innodb_flush_method.
The system tablespace stores the InnoDB
data dictionary and undo logs, and has a 64TB size limit. By
comparison, each file-per-table tablespace has a 64TB size
limit, which provides room for growth. See
Section 14.11.8, “Limits on InnoDB Tables” for related information.
With file-per-table tablespaces, each table may have unused space, which can only be utilized by rows of the same table. This could lead to wasted space if not properly managed.
fsync operations must run on each open
table rather than on a single file. Because there is a
separate fsync operation for each file,
write operations on multiple tables cannot be combined into a
single I/O operation. This may require
InnoDB to perform a higher total number of
fsync operations.
mysqld must keep one open file handle per table, which may impact performance if you have numerous tables in file-per-table tablespaces.
More file descriptors are used.
If backward compatibility with MySQL 5.1 is a concern, be
aware that enabling
innodb_file_per_table means
that an ALTER TABLE operation
will move an InnoDB table from the system
tablespace to an individual .ibd file in
cases where ALTER TABLE
recreates the table (ALTER OFFLINE).
For example, when restructuring the clustered index for an
InnoDB table, the table is re-created using
the current setting for
innodb_file_per_table. This
behavior does not apply when adding or dropping
InnoDB secondary indexes. When a secondary
index is created without rebuilding the table, the index is
stored in the same file as the table data, regardless of the
current innodb_file_per_table
setting.
If many tables are growing there is potential for more
fragmentation which can impede DROP
TABLE and table scan performance. However, when
fragmentation is managed, having files in their own tablespace
can improve performance.
The buffer pool is scanned when dropping a file-per-table tablespace, which can take several seconds for buffer pools that are tens of gigabytes in size. The scan is performed with a broad internal lock, which may delay other operations. Tables in the system tablespace are not affected.
The
innodb_autoextend_increment
variable, which defines increment size (in MB) for extending
the size of an auto-extending shared tablespace file when it
becomes full, does not apply to file-per-table tablespace
files, which are auto-extending regardless of the
innodb_autoextend_increment
setting. The initial extensions are by small amounts, after
which extensions occur in increments of 4MB.
To enable file-per-table tablespaces, start the server with the
--innodb_file_per_table option. For
example, add a line to the [mysqld] section of
my.cnf:
[mysqld] innodb_file_per_table=1
With innodb_file_per_table
enabled, InnoDB stores each newly created table
into its own
tbl_name.ibdMyISAM storage engine does, but
MyISAM divides the table into a
tbl_name.MYDtbl_name.MYIInnoDB, the data and the indexes are
stored together in the .ibd file. The
tbl_name.frm
If you remove the
innodb_file_per_table line from
my.cnf and restart the server, newly created
InnoDB tables are created inside the shared
tablespace files again.
To move a table from the system tablespace to its own tablespace,
change the innodb_file_per_table
setting and rebuild the table:
SET GLOBAL innodb_file_per_table=1;
ALTER TABLE table_name ENGINE=InnoDB;
InnoDB requires the shared tablespace to
store its internal data dictionary and undo logs. The
.ibd files alone are not sufficient for
InnoDB to operate.
When a table is moved out of the system tablespace into its own
.ibd file, the data files that make up the
system tablespace remain the same size. The space formerly
occupied by the table can be reused for new
InnoDB data, but is not reclaimed for use by
the operating system. When moving large
InnoDB tables out of the system tablespace,
where disk space is limited, you might prefer to turn on
innodb_file_per_table and then
recreate the entire instance using the
mysqldump command.
You cannot freely move .ibd files between
database directories as you can with MyISAM
table files. The table definition stored in the
InnoDB shared tablespace includes the database
name. The transaction IDs and log sequence numbers stored in the
tablespace files also differ between databases.
To move an .ibd file and the associated table
from one database to another, use a RENAME
TABLE statement:
RENAME TABLEdb1.tbl_nameTOdb2.tbl_name;
If you have a “clean” backup of an
.ibd file, you can restore it to the MySQL
installation from which it originated as follows:
The table must not have been dropped or truncated since you
copied the .ibd file, because doing so
changes the table ID stored inside the tablespace.
Issue this ALTER TABLE
statement to delete the current .ibd
file:
ALTER TABLE tbl_name DISCARD TABLESPACE;
Copy the backup .ibd file to the proper
database directory.
Issue this ALTER TABLE
statement to tell InnoDB to use the new
.ibd file for the table:
ALTER TABLE tbl_name IMPORT TABLESPACE;
In this context, a “clean” .ibd
file backup is one for which the following requirements are
satisfied:
There are no uncommitted modifications by transactions in the
.ibd file.
There are no unmerged change buffer entries in the
.ibd file.
Purge has removed all delete-marked index records from the
.ibd file.
mysqld has flushed all modified pages of
the .ibd file from the buffer pool to the
file.
You can make a clean backup .ibd file using
the following method:
Stop all activity from the mysqld server and commit all transactions.
Wait until SHOW
ENGINE INNODB STATUS shows that there are no active
transactions in the database, and the main thread status of
InnoDB is Waiting for server
activity. Then you can make a copy of the
.ibd file.
Another method for making a clean copy of an
.ibd file is to use the MySQL Enterprise
Backup product:
Use MySQL Enterprise Backup to back up the
InnoDB installation.
Start a second mysqld server on the backup
and let it clean up the .ibd files in the
backup.