14.5 InnoDB Tablespace Management
14.5.1 Resizing the InnoDB System Tablespace
14.5.2 Changing the Number or Size of InnoDB Redo Log Files
14.5.3 Using Raw Disk Partitions for the System Tablespace
14.5.4 InnoDB File-Per-Table Tablespaces
14.5.5 Creating a File-Per-Table Tablespace Outside the Data Directory
14.5.6 Copying File-Per-Table Tablespaces to Another Server
14.5.7 Storing InnoDB Undo Logs in Separate Tablespaces
14.5.1 Resizing the InnoDB System Tablespace
This section describes how to increase or decrease the size of the InnoDB system tablespace.
这一章节讲述了如何增加减少InnoDB系统表空间的大小。
Increasing the Size of the InnoDB System Tablespace
The easiest way to increase the size of the InnoDB system tablespace is to configure it from the beginning to be auto-extending. Specify the autoextend attribute for the last data file in the tablespace definition. Then InnoDB increases the size of that file automatically in 8MB increments when it runs out of space. The increment size can be changed by setting the value of the innodb_autoextend_increment system variable, which is measured in megabytes.
增加InnoDB系统表空间大小最简单的方法是在一开始的时候就把它配置成自动扩展的。在表空间的定义中指定最后数据文件自动扩展，当空间满的时候InnoDB会自动为那个文件增加8MB。增长的值可以通过innodb_autoextend_increment系统参数设定，单位是M。
You can expand the system tablespace by a defined amount by adding another data file:
你可以通过增加另一个数据文件来扩展系统表空间：
1.Shut down the MySQL server.
1.关闭MySQL实例。
2.If the previous last data file is defined with the keyword autoextend, change its definition to use a fixed size, based on how large it has actually grown. Check the size of the data file, round it down to the closest multiple of 1024 × 1024 bytes (= 1MB), and specify this rounded size explicitly in innodb_data_file_path.
2.如果之前的最后一个文件已经定义自动扩展了，那就根据表空间的实际增长情况修改增长值。检查数据文件的大小， round it down to the closest multiple of 1024 × 1024 bytes (= 1MB), and specify this rounded size explicitly in innodb_data_file_path.
3.Add a new data file to the end of innodb_data_file_path, optionally making that file auto-extending. Only the last data file in the innodb_data_file_path can be specified as auto-extending.
3.在innodb_data_file_path的尾部添加一个新的文件，并指定自动扩展。只有innodb_data_file_path里最后一个数据文件可以被指定为自动扩展。
4.Start the MySQL server again.
4.再次启动MySQL实例。
For example, this tablespace has just one auto-extending data file ibdata1:
例如，这个表空间只有一个自动扩展数据文件ibdata1：
innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:10M:autoextend
Suppose that this data file, over time, has grown to 988MB. Here is the configuration line after modifying the original data file to use a fixed size and adding a new auto-extending data file:
假设这个数据文件，随着时间已经增长到988MB。这里就配置修改了原始数据使用一个固定的大小并添加一个新的自动扩展的数据文件：
innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:988M;/disk2/ibdata2:50M:autoextend
When you add a new data file to the system tablespace configuration, make sure that the filename does not refer to an existing file. InnoDB creates and initializes the file when you restart the server.
当你要像系统表空间添加一个新的数据文件的时候，要确保文件名不会引用到现有的文件。InnoDB会在你重启实例的时候创建并初始化这个文件。
Decreasing the Size of the InnoDB System Tablespace
You cannot remove a data file from the system tablespace. To decrease the system tablespace size, use this procedure:
你不能重系统表空间里移除数据文件。要减少系统表空间大小的话可以进行如下的操作：
1.Use mysqldump to dump all your InnoDB tables, including InnoDB tables located in the MySQL database. As of 5.6, there are five InnoDB tables included in the MySQL database:
1.使用mysqldump导出你所有的InnoDB表，包括MySQL数据库里的InnoDB表。从5.6开始，包括在MySQL数据库里的有5个InnoDB表：
mysql> select table_name from information_schema.tables where table_schema='mysql' and engine='InnoDB';
+----------------------+
| table_name |
+----------------------+
| innodb_index_stats |
| innodb_table_stats |
| slave_master_info |
| slave_relay_log_info |
| slave_worker_info |
+----------------------+
5 rows in set (0.00 sec)
2.Stop the server.
2.关闭实例。
3.Remove all the existing tablespace files (*.ibd), including the ibdata and ib_log files. Do not forget to remove *.ibd files for tables located in the MySQL database.
3.移除所有现存的表空间文件(*.ibd)，包括ibdata 和ib_log文件。还有要不忘记移除MySQL数据库里的*.ibd文件。
4.Remove any .frm files for InnoDB tables.
4.移除InnoDB表的.frm文件。
5.Configure a new tablespace.
5.配置一个新的表空间。
6.Restart the server.
6.重启实例。
7.Import the dump files.
7.导入dump文件。
Note
If your databases only use the InnoDB engine, it may be simpler to dump all databases, stop the server, remove all databases and InnoDB log files, restart the server, and import the dump files.
如果你的数据库只使用了InnoDB引擎，那么最简单的办法是导出所有的数据库，停止实例，移除所有的数据库和InnoDB日志文件，重启实例，再导入dump文件。
14.5.2 Changing the Number or Size of InnoDB Redo Log Files
To change the number or size of InnoDB redo log files in MySQL 5.6.7 or earlier, perform the following steps:
在MySQL5.6.7或者更早的版本更改InnoDB redo log文件的数量或大小，要执行下面的步骤：
1.If innodb_fast_shutdown is set to 2, set innodb_fast_shutdown to 1:
1.如果innodb_fast_shutdown的设置成2，那么改成1：
mysql> SET GLOBAL innodb_fast_shutdown = 1;
2.After ensuring that innodb_fast_shutdown is not set to 2, stop the MySQL server and make sure that it shuts down without errors (to ensure that there is no information for outstanding transactions in the log).
2.在确保innodb_fast_shutdown设置的不是2之后，停止MySQL实例并确保没有错误（确保在log里面没有未完成事务的信息）。
3.Copy the old log files into a safe place in case something went wrong during the shutdown and you need them to recover the tablespace.
3.把老的log文件复制到一个安全的地方，以防止关闭报错的时候用来recover表空间。
4.Delete the old log files from the log file directory.
4.在日志文件目录删除老的日志文件。
5.Edit my.cnf to change the log file configuration.
5.编辑my.cnf修改日志文件配置。
6.Start the MySQL server again. mysqld sees that no InnoDB log files exist at startup and creates new ones.
6.启动MySQL实例。mysqld的在启动的时候看到没有InnoDB日志文件会创建一个新的。
As of MySQL 5.6.8, the innodb_fast_shutdown setting is no longer relevant when changing the number or the size of InnoDB log files. Additionally, you are no longer required remove old log files, although you may still want to copy the old log files to a safe place, as a backup. To change the number or size of InnoDB log files, perform the following steps:
从MySQL5.6.8开始，innodb_fast_shutdown设置已经和修改InnoDB日志文件的数量或大小没有关系了。另外，你也不再需要移除老的日志文件，当然你仍然可以把老的日志文件复制到一个安全的地方作为备份。要修改InnoDB日志文件的数量或大小可以执行以下的步骤：
1.Stop the MySQL server and make sure that it shuts down without errors.
1.关闭MySQL实例并确保没有报错。
2.Edit my.cnf to change the log file configuration. To change the log file size, configure innodb_log_file_size. To increase the number of log files, configure innodb_log_files_in_group.
2.编译my.cnf文件修改日志文件配置。innodb_log_file_size配置日志文件的大小。innodb_log_files_in_group配置日志文件的数量。
3.Start the MySQL server again.
3.启动MySQL实例。
If InnoDB detects that the innodb_log_file_size differs from the redo log file size, it will write a log checkpoint, close and remove the old log files, create new log files at the requested size, and open the new log files.
如果InnoDB发现innodb_log_file_size的值不同于redo log文件的大小，它会写下日志的checkpoint，关闭并删除老的日志文件，再创建一个符合大小要求的新的日志文件，最后打开新的日志文件。
14.5.3 Using Raw Disk Partitions for the System Tablespace
You can use raw disk partitions as data files in the InnoDB system tablespace. This technique enables nonbuffered I/O on Windows and on some Linux and Unix systems without file system overhead. Perform tests with and without raw partitions to verify whether this change actually improves performance on your system.
你可以使用raw磁盘分区来作为InnoDB系统表空间的数据文件。这种方式能够使得在Windows以及一些Linux平台上使用没有buffer的I/O，这样就减少了文件系统的损耗。分别对使用或没使用raw分区的情况进行测试，经验证这样的修改对于的你系统是否有实际上的性能提升。
When you use a raw disk partition, ensure that the user ID that runs the MySQL server has read and write privileges for that partition. For example, if you run the server as the mysql user, the partition must be readable and writeable by mysql. If you run the server with the --memlock option, the server must be run as root, so the partition must be readable and writeable by root.
当你使用了raw磁盘分区，要确保运行MySQL实例的用户ID有读写分区的权限。例如，你以mysql用户来运行实例的，那么mysql用户对于分区必须要能读能写。如果你想要以--memlock的参数运行的实例，那必须要以root来运行，那么分区对于root也必须是要可读可写的。
The procedures described below involve option file modification. For additional information, see Section 4.2.6, "Using Option Files".
下面涉及的配置文件修改的相关信息可以查看Section 4.2.6, "Using Option Files"。
Allocating a Raw Disk Partition on Linux and Unix Systems
1.When you create a new data file, specify the keyword newraw immediately after the data file size for the innodb_data_file_path option. The partition must be at least as large as the size that you specify. Note that 1MB in InnoDB is 1024 × 1024 bytes, whereas 1MB in disk specifications usually means 1,000,000 bytes.
1.当你创建一个新数据文件的时候，在innodb_data_file_path文件大小的后面指定关键字newraw。分区也必须至少达到你指定的大小。还有要注意的是在InnoDB里面1MB等于1024 × 1024 bytes，然而在磁盘规格上1MB通常是1,000,000 bytes。
[mysqld]
innodb_data_home_dir=
innodb_data_file_path=/dev/hdd1:3Gnewraw;/dev/hdd2:2Gnewraw
2.Restart the server. InnoDB notices the newraw keyword and initializes the new partition. However, do not create or change any InnoDB tables yet. Otherwise, when you next restart the server, InnoDB reinitializes the partition and your changes are lost. (As a safety measure InnoDB prevents users from modifying data when any partition with newraw is specified.)
2.重启实例。InnoDB注意到newraw关键字会初始化这个新的分区。但是，不会创建或修改任何的InnoDB表。要不然，当你再次重启实例的时候，InnoDB会再次初始化分区，你的修改也会丢失。（作为一种安全的方式当任何分区指定了newraw，InnoDB会阻止用户修改数据。）
3.After InnoDB has initialized the new partition, stop the server, change newraw in the data file specification to raw:
3.在InnoDB初始完新的分区之后，停止实例，为其他的raw数据文件指定newraw ：
[mysqld]
innodb_data_home_dir=
innodb_data_file_path=/dev/hdd1:3Graw;/dev/hdd2:2Graw
4.Restart the server. InnoDB now permits changes to be made.
4.重启实例。现在InnoDB允许可以修改了。
Allocating a Raw Disk Partition on Windows
On Windows systems, the same steps and accompanying guidelines described for Linux and Unix systems apply except that the innodb_data_file_path setting differs slightly on Windows.
在Windows系统上，除了innodb_data_file_path的配置有些许不同，其他的步骤和Linux平台的一样。
1.When you create a new data file, specify the keyword newraw immediately after the data file size for the innodb_data_file_path option:
1.当你创建一个新数据文件的时候，在innodb_data_file_path的数据文件的大小后面指定keyword 关键字：
[mysqld]
innodb_data_home_dir=
innodb_data_file_path=//./D::10Gnewraw
The //./ corresponds to the Windows syntax of \. for accessing physical drives. In the example above, D: is the drive letter of the partition.
//./对应Windows的\.。在上面的例子里，D: 是分区的驱动字符。
2.Restart the server. InnoDB notices the newraw keyword and initializes the new partition.
2.重启实例。InnoDB注意到newraw 关键字会初始化新的分区。
3.After InnoDB has initialized the new partition, stop the server, change newraw in the data file specification to raw:
3.在InnoDB初始完新的分区之后，停止实例，为其他的raw数据文件指定newraw：
[mysqld]
innodb_data_home_dir=
innodb_data_file_path=//./D::10Graw
4.Restart the server. InnoDB now permits changes to be made.
4.重启实例。InnoDB现在允许修改。
14.5.4 InnoDB File-Per-Table Tablespaces
14.5.4.1 Enabling and Disabling File-Per-Table Tablespaces
Historically, all 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. InnoDB's file-per-table tablespace feature provides a more flexible alternative, where each InnoDB table and its indexes are stored in a separate .ibd data file. Each such .ibd data file represents an individual tablespace. This feature is controlled by the innodb_file_per_table configuration option, which is enabled by default in MySQL 5.6.6 and higher.
在以前，所有的InnoDB表和索引都是存储在系统表空间里的。这种单片的方法是针对于整个机器都是用于数据库处理的，这样可精心计划数据的增长，MySQL分配的任何磁盘存储也不会用于其他的目的。InnoDB file-per-table 表空间特性提供了一种更灵活的方式，每个InnoDB的表和索引都存储在各自.ibd数据文件里。每个.ibd数据文件都代表了一个单独的表空间。这种特性是由innodb_file_per_table配置参数控制的，在MySQL5.6.6及更高的版本里默认是开启的。
Advantages of File-Per-Table Tablespaces
Potential Disadvantages of File-Per-Table Tablespaces
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.
例如，当为一个InnoDB表重建clustered index的时候，使用当前的innodb_file_per_table设定表会重建。但是添加或删除InnoDB secondary index的时候不是这样的。当创建一个secondary index而不重建表的时候，索引会存储在表数据的相同的文件里，而不管innodb_file_per_table的设定是什么。
14.5.4.1 Enabling and Disabling File-Per-Table Tablespaces
The innodb_file_per_table option is enabled by default as of MySQL 5.6.6.
innodb_file_per_table参数在MySQL5.6.6里面默认是开启的。
To set the innodb_file_per_table option at startup, start the server with the --innodb_file_per_table command-line option, or add this line to the [mysqld] section of my.cnf:
要在启动的时候设定innodb_file_per_table参数，可以在启动的命令行里使用--innodb_file_per_table ，或者在my.cnf的 [mysqld]里面添加下面的内容：
[mysqld]
innodb_file_per_table=1
You can also set innodb_file_per_table dynamically, while the server is running:
你还可以在实例运行的时候动态设定innodb_file_per_table：
SET GLOBAL innodb_file_per_table=1;
With innodb_file_per_table enabled, you can store InnoDB tables in a tbl_name.ibd file. Unlike the MyISAM storage engine, with its separate tbl_name.MYD and tbl_name.MYI files for indexes and data, InnoDB stores the data and the indexes together in a single .ibd file. The tbl_name.frm file is still created as usual.
在innodb_file_per_table开启的时候，你可以把InnoDB表存储到一个tbl_name.ibd文件里。不像MyISAM存储引擎，分别在tbl_name.MYD and tbl_name.MYI文件里存储索引和数据，InnoDB会把数据和索引都存储在一个.ibd文件里。tbl_name.frm通常情况下也还是会被创建的。
If you disable innodb_file_per_table in your startup options and restart the server, or disable it with the SET GLOBAL command, InnoDB creates new tables inside the system tablespace.
如果你在启动和重启的时候关闭了innodb_file_per_table，又或者使用SET GLOBAL动态关闭了它，InnoDB会把新的表创建到系统表空间里。
You can always read and write any InnoDB tables, regardless of the file-per-table setting.
你仍然可以读写任何的InnoDB表，而不用去管file-per-table的设定。
To move a table from the system tablespace to its own tablespace, change the innodb_file_per_table setting and rebuild the table:
要把一个表从系统表空间移动到它自己的表空间里，可以修改innodb_file_per_table的设定并重建表：
SET GLOBAL innodb_file_per_table=1;
ALTER TABLE table_name ENGINE=InnoDB;
Note
InnoDB always needs the system tablespace because it puts its internal data dictionary and undo logs there. The .ibd files are not sufficient for InnoDB to operate.
InnoDB仍然还是需要系统表空间的，因为里面存放了内部的数据字典以及undo log。单纯的.ibd文件对于InnoDB的操作还是不够的。
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 may prefer to enable innodb_file_per_table and recreate the entire instance using the mysqldump command.
当一个表从系统表空间移动到它自己的表空间的时候，系统表空间的大小不会减小。这个表之前占用的空间可以给新的InnoDB数据使用，但不会被操作系统回收使用。当要把很多的表从系统表空间里移除的时候要注意磁盘空间的限制，你最好是开启 innodb_file_per_table在使用mysqldump重建整个实例。
14.5.5 Creating a File-Per-Table Tablespace Outside the Data Directory
To create a new InnoDB file-per-table tablespace in a specific location outside the MySQL data directory, use the DATA DIRECTORY = absolute_path_to_directory clause of the CREATE TABLE statement.
要在MySQL数据目录之外的地方创建一个新的InnoDB file-per-table表空间，可以在CREATE TABLE 的时候使用DATA DIRECTORY = absolute_path_to_directory子句。
Plan the location in advance, because you cannot use the DATA DIRECTORY clause with the ALTER TABLE statement. The directory you specify could be on another storage device with particular performance or capacity characteristics, such as a fast SSD or a high-capacity HDD.
要预先规划数据存放的位置，因为你不能在ALTER TABLE的时候使用DATA DIRECTORY子句。你指定的目录可以是 另一个有特别性能优势或者存储能力的磁盘，例如更快的SSD或者更可靠的HDD。
Within the destination directory, MySQL creates a subdirectory corresponding to the database name, and within that a .ibd file for the new table. In the database directory beneath the MySQL DATADIR directory, MySQL creates a table_name.isl file containing the path name for the table. The .isl file is treated by MySQL like a symbolic link. (Using actual symbolic links has never been supported for InnoDB tables.)
在目标目录里，MySQL会创建一个和数据库名相关的子目录，并在里面存放新建表的ibd文件。MySQL DATADIR目录下面的数据库目录里，MySQL会创建一个包含表路径名的 table_name.isl文件。这个.isl文件对MySQL就如同一个symbolic link一样。（InnoDB表从未支持过symbolic links。）
The following example demonstrates creating a file-per-table tablespace outside the MySQL data directory. It shows the .ibd created in the specified directory, and the .isl created in the database directory beneath the MySQL data directory.
下面的例子示范了在MySQL数据目录之外创建一个file-per-table表空间。这里显示了.ibd指定的创建目录，以及MySQL数据目录下的数据库目录里面创建的.isl。
mysql> USE test;
Database changed
mysql> SHOW VARIABLES LIKE 'innodb_file_per_table';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_file_per_table | ON |
+-----------------------+-------+
1 row in set (0.00 sec)
mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY) DATA DIRECTORY = '/alternative/directory';
Query OK, 0 rows affected (0.03 sec)
# MySQL creates a .ibd file for the new table in a subdirectory that corresponding
# to the database name
db_user@ubuntu:~/alternative/directory/test$ ls
t1.ibd
# MySQL creates a .isl file containing the path name for the table in a directory
# beneath the MySQL data directory
db_user@ubuntu:~/mysql/data/test$ ls
db.opt t1.frm t1.isl
Usage Notes:
A server restart might fail if the .ibd file is still not at the expected path. In this case, manually remove the table_name.isl file in the database directory, and after restarting perform a DROP TABLE to delete the .frm file and remove the information about the table from the data dictionary.
如果.idb文件不在其应该在的路径的话，实例重启可能会失败。在这种情况下，在数据库目录里面手动删除table_name.isl文件，在重启之后执行DROP TABLE删除.frm文件并重数据目录里面删除这个表的相关信息。
14.5.6 Copying File-Per-Table Tablespaces to Another Server
This section describes how to copy file-per-table tablespaces from one database server to another, otherwise known as the Transportable Tablespaces feature.
这一章节讲述了表空间传输(Transportable Tablespaces)的特性，把一个file-per-table表空间从一个数据库实例复制到到另一个。
For information about other InnoDB table copying methods, see Section 14.6.2, "Moving or Copying InnoDB Tables to Another Machine".
InnoDB表复制的的其他方法可见Section 14.6.2, "Moving or Copying InnoDB Tables to Another Machine"。
There are many reasons why you might copy an InnoDB file-per-table tablespace to a different database server:
下面是讲述的是为什么要把一个InnoDB file-per-table表空间复制到另一个实例上：
Limitations and Usage Notes
Message: InnoDB: IO Read error: (2, No such file or directory) Error opening '.
test .cfg', will attempt to import without schema verification
1 row in set (0.00 sec)
The ability to import without a .cfg file may be more convenient when no schema mismatches are expected. Additionally, the ability to import without a .cfg file could be useful in crash recovery scenarios in which metadata cannot be collected from an .ibd file.
当预期没有schema不匹配的时候，不导入.cfg文件可能会更方便。另外，在崩溃恢复的场景中不导入.cfg会更有用处，因为.idb文件是不会收集元数据的。
[mysqld]
lower_case_table_names=1
Example: Copying a File-Per-Table Tablespace From One Server To Another
This procedure demonstrates how to copy a table stored in a file-per-table tablespace from a running MySQL server instance to another running instance. The same procedure with minor adjustments can be used to perform a full table restore on the same instance.
下面的过程演示了如何从一个正在运行的实例里把一个存储在file-per-table表空间里的表复制到另一个正在运行的实例上。对于在同一个实例上进行全表的恢复只需要对这个过程进行微小的调整。
1.On the source server, create a table if one does not already exist:
在源端创建以一个不同名的新表：
mysql> use test;
mysql> CREATE TABLE t(c1 INT) engine=InnoDB;
2.On the destination server, create a table if one does not exist:
在远端也创建同样的一个表：
mysql> use test;
mysql> CREATE TABLE t(c1 INT) engine=InnoDB;
3.On the destination server, discard the existing tablespace. (Before a tablespace can be imported, InnoDB must discard the tablespace that is attached to the receiving table.)
在远端，discard现有的表空间。（在表空间导入之前，InnoDB必须discard表空间再附上收到的表。）
mysql> ALTER TABLE t DISCARD TABLESPACE;
4.On the source server, run FLUSH TABLES ... FOR EXPORT to quiesce the table and create the .cfg metadata file:
在源端，运行FLUSH TABLES ... FOR EXPORT静默(quiesce )表并创建.cfg元数据文件：
mysql> use test;
mysql> FLUSH TABLES t FOR EXPORT;
The metadata (.cfg) file is created in the InnoDB data directory.
元数据(.cfg)文件创建在InnoDB的数据目录里。
Note
FLUSH TABLES ... FOR EXPORT is available as of MySQL 5.6.6. The statement ensures that changes to the named tables have been flushed to disk so that binary table copies can be made while the server is running. When FLUSH TABLES ... FOR EXPORT is run, InnoDB produces a .cfg file in the same database directory as the table. The .cfg file contains metadata used for schema verification when importing the tablespace file.
FLUSH TABLES ... FOR EXPORT是从MySQL5.6.6才开始可用的。这个语句会确保表的更新已经被刷新到了磁盘上，这样二进制的表文件才能在实例正在运行的情况下进行复制。当运行FLUSH TABLES ... FOR EXPORT的时候，InnoDB会在表相同的数据库目录下面产生一个.cfg文件。这个.cfg文件包含了在导入表空间文件时用于schema验证的元数据。
5.Copy the .ibd file and .cfg metadata file from the source server to the destination server. For example:
从源端复制.ibd文件以及.cfg元数据文件到远端：
shell> scp /path/to/datadir/test/t.{ibd,cfg} destination-server:/path/to/datadir/test
Note
The .ibd file and .cfg file must be copied before releasing the shared locks, as described in the next step.
.idb文件和.cfg文件必须在释放共享锁之前复制，正如下一步所描述的。
6.On the source server, use UNLOCK TABLES to release the locks acquired by FLUSH TABLES ... FOR EXPORT:
在源端，使用UNLOCK TABLES释放所有FLUSH TABLES ... FOR EXPORT获取的锁：
mysql> use test;
mysql> UNLOCK TABLES;
7.On the destination server, import the tablespace:
在远端，导入表空间：
mysql> use test;
mysql> ALTER TABLE t IMPORT TABLESPACE;
Note
The ALTER TABLE ... IMPORT TABLESPACE feature does not enforce foreign key constraints on imported data. If there are foreign key constraints between tables, all tables should be exported at the same (logical) point in time. In this case you would stop updating the tables, commit all transactions, acquire shared locks on the tables, and then perform the export operation.
ALTER TABLE ... IMPORT TABLESPACE特性不会在导入的数据上实施外键约束。如果表上没有外键约束，所有的表必须在同一个时间点上一次都导出。这种情况下你要停止对表的更新，提交所有的事务，在表上施加共享锁，之后才能执行导出操作。
Transportable Tablespace Internals
The following information describes internals and error log messaging for the transportable tablespaces copy procedure.
下面的内容描述了表空间传输过程中的内部原理和错误日志信息。
When ALTER TABLE ... DISCARD TABLESPACE is run on the destination instance:
当在远端实例运行ALTER TABLE ... DISCARD TABLESPACE的时候：
When FLUSH TABLES ... FOR EXPORT is run on the source instance:
当在源端运行FLUSH TABLES ... FOR EXPORT的时候：
Expected error log messages for this operation:
这个操作在错误日志里预期的信息如下：
2013-07-18 14:47:31 34471 [Note] InnoDB: Sync to disk of '"test"."t"' started.
2013-07-18 14:47:31 34471 [Note] InnoDB: Stopping purge
2013-07-18 14:47:31 34471 [Note] InnoDB: Writing table metadata to './test/t.cfg'
2013-07-18 14:47:31 34471 [Note] InnoDB: Table '"test"."t"' flushed to disk
When UNLOCK TABLES is run on the source instance:
当在源端运行UNLOCK TABLES的时候：
Expected error log messages for this operation:
这个操作在错误日志里预期的信息如下：
2013-07-18 15:01:40 34471 [Note] InnoDB: Deleting the meta-data file './test/t.cfg'
2013-07-18 15:01:40 34471 [Note] InnoDB: Resuming purge
When ALTER TABLE ... IMPORT TABLESPACE is run on the destination instance, the import algorithm performs the following operations for each tablespace being imported:
当在远端实例运行ALTER TABLE ... IMPORT TABLESPACE的时候，导入算法会为每个导入的表空间执行下面的操作：
Expected error log messages for this operation:
这个操作在错误日志里预期的信息如下：
2013-07-18 15:15:01 34960 [Note] InnoDB: Importing tablespace for table 'test/t' that was exported from host 'ubuntu'
2013-07-18 15:15:01 34960 [Note] InnoDB: Phase I - Update all pages
2013-07-18 15:15:01 34960 [Note] InnoDB: Sync to disk
2013-07-18 15:15:01 34960 [Note] InnoDB: Sync to disk - done!
2013-07-18 15:15:01 34960 [Note] InnoDB: Phase III - Flush changes to disk
2013-07-18 15:15:01 34960 [Note] InnoDB: Phase IV - Flush complete
Note
You may also receive a warning that a tablespace is discarded (if you discarded the tablespace for the destination table) and a message stating that statistics could not be calculated due to a missing .ibd file:
表空被分离的时候你也可能会收到一个警告（如果你是为远端的表进行表空间的分离）：由于遗失了.ibd文件无法计算统计信息：
2013-07-18 15:14:38 34960 [Warning] InnoDB: Table "test"."t" tablespace is set as discarded.
2013-07-18 15:14:38 7f34d9a37700 InnoDB: cannot calculate statistics for table "test"."t" because the .ibd file is missing. For help, please refer to
http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html
14.5.7 Storing InnoDB Undo Logs in Separate Tablespaces
As of MySQL 5.6.3, you can store InnoDB undo logs in one or more separate undo tablespaces outside of the system tablespace. This layout is different from the default configuration where the undo log is part of the system tablespace. The I/O patterns for the undo log make these tablespaces good candidates to move to SSD storage, while keeping the system tablespace on hard disk storage. Users cannot drop the separate tablespaces created to hold InnoDB undo logs, or the individual segments inside those tablespaces.
从MySQL5.6.3开始，你可以把InnoDB的undo log存储在一个或者多个分离在系统表空间之外的undo表空间里。这种布局不是默认的配置，默认的是undo log是被放置在系统表空间里的。undo log的I/O模式使得最好能够把这些undo表空间移动到SSD存储上，而把系统表空间放在普通的硬盘上。用户是无法删除用于存放InnoDB undo log的表空间的，又或者是这些表空间里的个别segment。
Because these files handle I/O operations formerly done inside the system tablespace, we broaden the definition of system tablespace to include these new files.
因为从前这些文件都是在系统表空间里处理I/O操作的，我们放宽的系统表空间定义也包括这些新的文件。
Undo logs are also referred to as rollback segments.
undo log仍然被称为回滚段。
This feature involves the following new or renamed configuration options:
新的特性涉及了下面新的或者重命令的配置参数：
Because the InnoDB undo log feature involves setting two non-dynamic startup variables (innodb_undo_tablespaces and innodb_undo_directory), this feature can only be enabled when initializing a MySQL instance.
因为InnoDB undo log的特性涉及了设置两个非动态的启动变量(innodb_undo_tablespaces and innodb_undo_directory)，所以只有在初始化MySQL实例的时候才能启动新的特性。
Usage Notes
To use this feature, follow these steps:
使用新的特性要跟随下面的步骤：
1.Decide on a path to hold the undo logs. You will specify that path as the argument to the innodb_undo_directory option in your MySQL configuration file or startup script. For embedded MySQL installations, an absolute path must be specified.
决定保存undo log的路径。指定这个路径作为MySQL配置文件或者启动脚本里innodb_undo_directory参数的值。对于嵌入式的MySQL，则指定的必须是绝对路径。
2.Decide on a starting value for the innodb_undo_logs option. You can start with a relatively low value and increase it over time to examine the effect on performance.
决定innodb_undo_logs参数的起始值。开始的时候你可以设置一个相对较小的值，随着时间测试对性能的影响来逐步增加。
3.Decide on a non-zero value for the innodb_undo_tablespaces option. The multiple undo logs specified by the innodb_undo_logs value are divided between this number of separate tablespaces (represented by .ibd files). This value is fixed for the life of the MySQL instance, so if you are uncertain about the optimal value, estimate on the high side.
为innodb_undo_tablespaces参数决定一个非0的值。innodb_undo_logs的值指定了分割多个undo log表空间（代表.ibd文件）。这个值对MySQL实例一开始就是固定好的，所以如果你不确认这个参数的值，那就预估一个相对比较大。
4.Create a new MySQL instance, using the values you chose in the configuration file or in your MySQL startup script. Use a realistic workload with data volume similar to your production servers. Alternatively, use the transportable tablespaces feature to copy existing database tables to your newly configured MySQL instance. See Section 14.5.6, "Copying File-Per-Table Tablespaces to Another Server" for more information.
你可以在配置文件或者MySQL的启动脚本里面使用你选择的值来创建一个新的MySQL实例。使用和生产环境相似的数据负载量，或者从现有的数据库里使用表空间传输特性把表复制到新配置的MySQL实例里面，详见Section 14.5.6, "Copying File-Per-Table Tablespaces to Another Server"。
5.Benchmark the performance of I/O intensive workloads.
进行密集型I/O负载的性能基准测试。
7.Deploy a new production instance using the ideal settings for these options. Set it up as a slave server in a replication configuration, or transfer data from an earlier production instance.
对这些参数使用理想的设定来部署一个新的生产实例。在主从配置中把它设置成slave，或者从之前的生产实例上把数据传输过来。
Performance and Scalability Considerations
Keeping the undo logs in separate files allows the MySQL team to implement I/O and memory optimizations related to this transactional data. For example, because the undo data is written to disk and then rarely used (only in case of crash recovery), it does not need to be kept in the filesystem memory cache, in turn allowing a higher percentage of system memory to be devoted to the InnoDB buffer pool.
把undo log从系统表空间分离出来能够使得MySQL改进和事务数据相关的I/O和内存的优化。例如，因为undo数据写入到磁盘后就很少使用了（除非是崩溃恢复的情况），这也就不需要保持在文件系统的内存cache里，反过来运行也就允许更多的系统内存可用于InnoDB的buffer pool。
The typical SSD best practice of keeping the InnoDB system tablespace on a hard drive and moving the per-table tablespaces to SSD, is assisted by moving the undo information into separate tablespace files.
最佳的实践是把InnoDB的系统表空间放在普通的硬盘上，而把undo的表空间放到SSD的磁盘上。
Internals
The physical tablespace files are named undoN, where N is the space ID, including leading zeros.
物理的表空间文件命名为undoN，N表示的是space ID，including leading zeros。
MySQL instances containing separate undo tablespaces cannot be downgraded to earlier releases such as MySQL 5.5 or 5.1.
包含多个undo表空间的实例是不能降级到早先的版本的，例如MySQL5.5或者5.1。