InnoDB tables and indexes
were stored in the system
tablespace. This monolithic approach was targeted at
machines dedicated entirely to database processing, with carefully
planned data growth, where any disk storage allocated to MySQL
would never be needed for other purposes.
file-per-table mode is
a more flexible alternative, where you store each
InnoDB table and its indexes in a separate
file. Each such
represents a separate
tablespace. This mode is
controlled by the
configuration option, and is the default in MySQL 5.6.6 and
You can reclaim operating system disk space when truncating or
dropping a table. For tables created when file-per-table mode
is turned off, truncating or dropping the tables creates free
space internally in the
ibdata files but the
free space can only be used for new
TRUNCATE TABLE operation is
faster when run on individual
You can store specific tables on separate storage devices, for
I/O optimization, space management, or backup purposes. In
previous releases, you had to move entire database directories
to other drives and create symbolic links in the MySQL data
directory, as described in Section 126.96.36.199, “Using Symbolic Links”.
In MySQL 5.6 and higher, you can specify the location of each
table using the syntax
CREATE TABLE ... DATA
as explained in Section 188.8.131.52, “Specifying the Location of a Tablespace”.
You can run
OPTIMIZE TABLE to
compact or recreate a tablespace. When you run an
InnoDB will create a new
.ibd file with a temporary name, using
only the space required to store actual data. When the
optimization is complete,
.ibd file and replaces it with
.ibd file. If the previous
.ibd file had grown significantly but
actual data only accounted for a portion of its size, running
OPTIMIZE TABLE allows you to
reclaim the unused space.
You can move individual
rather than entire databases.
You can copy individual
InnoDB tables from
one MySQL instance to another (known as the
Tables created when
enabled can use the
Barracuda file format.
The Barracuda file format enables features such as
and dynamic row
formats. Tables created when
innodb_file_per_table is off
cannot use these features. To take advantage of these features
for an existing table, you can turn on the file-per-table
setting and run
existing table. Before converting tables, refer to
Section 184.108.40.206, “Converting Tables from
You can enable more efficient storage for tables with large BLOB or text columns using the dynamic row format.
may improve chances for a successful recovery and save time if
a corruption occurs, a server cannot be restarted, or backup
and binary logs are unavailable.
You can back up or restore a single table quickly, without
interrupting the use of other
tables, using the MySQL Enterprise Backup product. See
Backing Up and Restoring a Single
.ibd File for the procedure
File-per-table mode allows you to excluded tables from a backup. This is beneficial if you have tables that require backup less frequently or on a different schedule.
File-per-table mode is convenient for per-table status reporting when copying or backing up tables.
File-per-table mode allows you to 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
disabled, there is one shared tablespace (the system
tablespace) for tables, the data dictionary, and undo logs.
This single tablespace has a 64TB size limit. If
enabled, each table has its own tablespace, each with a 64TB
size limit. See Section E.10.3, “Limits on Table Size” for related
each table may have unused table space, which can only be
utilized by rows of the same table. This could lead to more
rather than less wasted table space if not properly managed.
fsync operations must run on each open
table rather than on a single file. Because there is a
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
mysqld must keep 1 open file handle per table, which may impact performance if you have numerous tables.
More file descriptors are used.
innodb_file_per_table is on
by default in MySQL 5.6.6 and higher. You may want to consider
disabling it if backward compatibility with MySQL 5.5 or 5.1
is a concern. Disabling
ALTER TABLE from
InnoDB table from the system
tablespace to an individual
.ibd file in
recreates the table (
For example, when restructuring the clustered index for an
InnoDB table, the table is re-created using
the current settings for
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
If many tables are growing there is potential for more
fragmentation which can impede
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 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 shared tablespace are not affected.
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. File-per-table tablespace files are auto-extending
regardless of the value of
The initial extensions are by small amounts, after which
extensions occur in increments of 4MB.