MySQL 5.6 Reference Manual-14.5 InnoDB Tablespace Management

時間 2019-11-17

標籤 mysql 5.6 reference manual 14.5 innodb tablespace management 欄目 MySQL 简体版

原文原文鏈接

14.5 InnoDB Tablespace Management html

14.5.1 Resizing the InnoDB System Tablespace mysql

14.5.2 Changing the Number or Size of InnoDB Redo Log Files ios

14.5.3 Using Raw Disk Partitions for the System Tablespace 算法

14.5.4 InnoDB File-Per-Table Tablespaces sql

14.5.5 Creating a File-Per-Table Tablespace Outside the Data Directory shell

14.5.6 Copying File-Per-Table Tablespaces to Another Server 數據庫

14.5.7 Storing InnoDB Undo Logs in Separate Tablespaces ubuntu

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

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 system tablespace creates free space internally in the system tablespace data files (ibdata files) which can only be used for new InnoDB data.
當truncate或者drop存儲在file-per-table表空間裏的表的時候，可以回收磁盤空間。而truncate或者drop存儲在系統表空間裏的表時回收的空間只能給新的InnoDB數據使用。

The TRUNCATE TABLE operation is faster when run on tables stored in file-per-table tablepaces.
表存儲在file-per-table表空間上，運行TRUNCATE TABLE操做速度更快。

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 8.12.4, "Using Symbolic Links". In MySQL 5.6.6 and higher, you can specify the location of each table using the syntax CREATE TABLE ... DATA DIRECTORY = absolute_path_to_directory, as explained in Section 14.5.5, "Creating a File-Per-Table Tablespace Outside the Data Directory".
你能夠爲I/O優化，空間管理，或者備份目的，把指定的表存儲在不一樣的存儲磁盤上。在之前的版本，你則要把整個數據目錄移動到其餘的磁盤上，在建立一個連接指向到MySQL的數據目錄，如Section 8.12.4, "Using Symbolic Links"所講述的。在MySQL5.6.6及更高的版本里，你能夠經過CREATE TABLE ... DATA DIRECTORY = absolute_path_to_directory來指定每一個表位置，如Section 14.5.5, "Creating a File-Per-Table Tablespace Outside the Data Directory"鎖描述的。

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.
你能夠運行OPTIMIZE TABLE來壓縮或者重建一個file-per-table表空間。當你運行了OPTIMIZE TABLE，InnoDB會使用一個臨時的名字建立一個新的.ibd文件，這個文件僅佔用實際數據的大小。當OPTIMIZE TABLE操做完成了，InnoDB會刪除舊的.ibd文件並用新的來替換它。若是之前的.ibd文件增加得很大可是實際數據只佔用了一部分，那麼運行OPTIMIZE TABLE能夠回收未使用的空間。

You can move individual InnoDB tables rather than entire databases.
你能夠移動個別表而不須要動整個數據庫。

You can copy individual InnoDB tables from one MySQL instance to another (known as the transportable tablespace feature).
你能夠從一個MySQL實例裏面複製個別表到另外一個實例裏面（表空間傳輸特性the transportable tablespace feature）。

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 t ENGINE=INNODB to place the table in a file-per-table tablespace. Before converting tables, refer to Section 14.6.4, "Converting Tables from MyISAM to InnoDB".
建立在file-per-table表空間裏的表使用了Barracuda的文件格式。Barracuda文件格式具備壓縮和動態的行格式。而建立在系統表空間裏的表是沒法使用這些特性的。現有的表要使用這些特性優點，要開始innodb_file_per_table設定並運行ALTER TABLE t ENGINE=INNODB把表放置到filer-per-table表空間裏。在轉換以前，請先參考Section 14.6.4, "Converting Tables from MyISAM to InnoDB"。

You can enable more efficient storage for tables with large BLOB or TEXT columns using the dynamic row format.
使用動態行格式(dynamic row format)可使得有不少BLOB或者TEXT列的表在存儲上更有效率。

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.
當發生故障實例沒法重啓的時候，或者備份和二進制日誌(binary logs)沒法使用的時候，file-per-table表空間可以提高recovery的成功概率並節約必定的時間。

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.
你可使用MySQL Enterprise Backup來快速備份或者恢復別個的表，而不會中斷其餘InnoDB表的使用。這在那種要求備份少許頻繁使用或者不一樣備份策略的表時就顯得很是有益了。相關部分能夠查看Partial Backup and Restore Options。

File-per-table tablespaces are convenient for per-table status reporting when copying or backing up tables.
當複製或者備份表的時候，file-per-table表空間爲每一個表報告狀態則更方便。

You can monitor table size at a file system level, without accessing MySQL.
你能夠在文件系統層面監控表的大小，而不須要訪問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 file-per-table tablespaces in conjunction with innodb_flush_method.
當innodb_flush_method被設置成O_DIRECT的時候普通的Linux文件系統是不容許對單個文件進行併發寫的。所以，當同時使用file-per-table表空間以及innodb_flush_method的時候可以提高性能。

The system tablespace stores the 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 you with room for growth. See Section C.10.3, "Limits on Table Size" for related information.
存儲數據目錄和undo log的系統表空間是有64TB的大小限制的。相比較之下，每一個表空間各有64TB的限制，這就爲你提供了更多的增加空間。詳見Section C.10.3, "Limits on Table Size" for related information。

Potential Disadvantages of File-Per-Table Tablespaces

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.
使用file-per-table表空間，每一個表均可能有未使用的空間，而這部分空間只能被它本身使用。若是管理不當的話就可能致使空間的浪費。

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.
fsync操做必須運行在每一個打開的表上，而不是一個單獨的文件。由於每一個文件分別都有一個fsync操做，因此多個表上的寫操做就沒法合併成一個I/O操做。這可能會使得InnoDB執行更多的fsync操做。

mysqld must keep one open file handle per table, which may impact performance if you have numerous tables in file-per-table tablespaces.
mysqld必須爲每一個表保持一個open file handle，若是你有不少的file-per-table表空間的表就可能會影響性能。

More file descriptors are used.
使用更多的file descriptors。

innodb_file_per_table is enabled by default in MySQL 5.6.6 and higher. You may consider disabling it if backward compatibility with MySQL 5.5 or 5.1 is a concern. Disabling innodb_file_per_table prevents ALTER TABLE from moving an InnoDB table from the system tablespace to an individual .ibd file in cases where ALTER TABLE recreates the table (ALGORITHM=COPY).
在MySQL5.6.6及更高版本里innodb_file_per_table默認是開啓的。若是要回退到MySQL5.5或者5.1的話就要考慮關閉它。關閉innodb_file_per_table可以阻止ALTER TABLE把一個InnoDB表從系統表空間移動到個別.ibd文件。這種狀況下ALTER TABLE會從新建立表(ALGORITHM=COPY)。

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的設定是什麼。

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.
若是不少的表增加得有了不少的碎片，這就會妨礙了DROP TABLE和表掃描的性能。然而，碎片可以有效管理的話，file-per-table表空間還能提高性能的。

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.
當刪除一個file-per-table表空間的時候是要掃描buffer pool的，這對於有幾十個G的buffer pool也是要花費很多時間（several seconds）的。這種掃描使用的是一種普遍的內部鎖，這會延遲其餘的操做。而在系統表空間裏的表則不會有這樣的影響。

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.
innodb_autoextend_increment變量定義了自動擴展的共享表空間滿的時候擴展的大小(in MB)，但這不適用於file-per-table表空間文件。file-per-table表空間的自動擴展與innodb_autoextend_increment的設定無關。最初的擴展是少許的，這以後會增加到4MB。

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:

MySQL initially holds the .ibd file open, preventing you from dismounting the device, but might eventually close the table if the server is busy. Be careful not to accidentally dismount an external device while MySQL is running, or to start MySQL while the device is disconnected. Attempting to access a table when the associated .ibd file is missing causes a serious error that requires a server restart.
MySQL最初爲保持.ibd文件的打開，已防止你卸載磁盤，但實例繁忙的時候仍是會關閉表的。在MySQL正在運行的時候要小心不要卸載外部磁盤，有或者是在未鏈接磁盤的狀況下啓動MySQL。嘗試去訪問那些.idb文件丟失的表會形成嚴重的錯誤並致使實例重啓。

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文件並重數據目錄裏面刪除這個表的相關信息。

Do not put MySQL tables on an NFS-mounted volume. NFS uses a message-passing protocol to write to files, which could cause data inconsistency if network messages are lost or received out of order.
不要把MySQL表放在NFS的捲上。NFS使用的是一種消息傳遞的協議寫文件，若是網絡消息丟失或者接受的消息不對可能會致使數據不一致。

If you use an LVM snapshot, file copy, or other file-based mechanism to back up the .ibd file, always use the FLUSH TABLES ... FOR EXPORT statement first to make sure all changes that were buffered in memory are flushed to disk before the backup occurs.
若是你使用了LVM的快照，文件拷貝，或者其餘基於文件的原理來備份.ibd文件，記住在這以前要使用FLUSH TABLES ... FOR EXPORT語句首先確保全部內存裏緩存的修改都已經刷新的到磁盤上。

The DATA DIRECTORY clause is a supported alternative to using symbolic links, which has always been problematic and was never supported for individual InnoDB tables.
相對於使用symbolic links，DATA DIRECTORY子句InnoDB是支持的。而symbolic links則一直是個問題，並且對於單個的InnoDB表是從未支持過的。

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表空間複製到另外一個實例上：

To run reports without putting extra load on a production server.
在生產實例上在不進行額外的數據加載的狀況下運行報表。

To set up identical data for a table on a new slave server.
在一個新的slave實例上創建一份相同的表數據。

To restore a backed-up version of a table after a problem or mistake.
出現問題或者人爲錯誤以後恢復表的一個備份版本。

As a faster way of moving data around than importing the results of a mysqldump command. The data is available immediately, rather than having to be re-inserted and the indexes rebuilt.
相比mysqldump的導入這是一個更爲快速的數據遷移方式。由於數據是當即可見的，不須要再次insert和創建索引。

To move a file-per-table tablespace to a server with storage medium that better suits system requirements. For example, you may want to have busy tables on an SSD device, or large tables on a high-capacity HDD device.
經過存儲媒介把轉移file-per-table表空間更適合系統要求。例如，你想把繁忙的表放到SSD磁盤上，或者把大的表發到大容量的HDD磁盤上。

Limitations and Usage Notes

The tablespace copy procedure is only possible when innodb_file_per_table is set to ON, which is the default setting as of MySQL 5.6.6. Tables residing in the shared system tablespace cannot be quiesced.
只有innodb_file_per_table被設置成ON的時候表空間複製纔是可能的。從MySQL5.6.6開始默認都是打開的。在共享的系統表空間裏的表是不支持的(cannot be quiesced)。

When a table is quiesced, only read-only transactions are allowed on the affected table.
當表是靜默的(quiesced)，那麼這個表值容許只讀事務。

When importing a tablespace, the page size must match the page size of the importing instance.
當導入一個表空間的時候，頁的大小必需要和導入的實例匹配。

DISCARD TABLESPACE is not supported for partitioned tables meaning that transportable tablespaces is also unsupported. If you run ALTER TABLE ... DISCARD TABLESPACE on a partitioned table, the following error is returned: ERROR 1031 (HY000): Table storage engine for 'part' doesn't have this option.
分區表不支持DISCARD TABLESPACE意味着表空間傳輸也不支持。若是你在一個分區表上運行ALTER TABLE ... DISCARD TABLESPACE，會報下面的錯誤：ERROR 1031 (HY000): Table storage engine for 'part' doesn't have this option。

DISCARD TABLESPACE is not supported for tablespaces with a parent-child (primary key-foreign key) relationship when foreign_key_checks is set to 1. Before discarding a tablespace for parent-child tables, set foreign_key_checks=0.
當oreign_key_checks被設置成1的時候有父子(primary key-foreign key)關係的表是不支持DISCARD TABLESPACE的。在discard一個有父子關係的表以前，要設置foreign_key_checks=0。

ALTER TABLE ... IMPORT TABLESPACE 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.
ALTER TABLE ... IMPORT TABLESPACE不能在導入的數據上實施外鍵約束。若是表上有外鍵，那麼就必須在同一個時間點一次導出全部的表。

ALTER TABLE ... IMPORT TABLESPACE does not require a .cfg metadata file to import a tablespace. However, metadata checks are not performed when importing without a .cfg file, and a warning similar to the following will be issued:
ALTER TABLE ... IMPORT TABLESPACE不要求把.cfg元數據文件導入到表空間。然而，不導入.cfg文件元數據檢查也不會執行，也就會獲得下面的警告：

Message: InnoDB: IO Read error: (2, No such file or directory) Error opening '.\

test\t.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文件是不會收集元數據的。

In MySQL 5.6 or later, importing a tablespace file from another server works if both servers have GA (General Availability) status and their versions are within the same series. Otherwise, the file must have been created on the server into which it is imported.
在MySQL5.6及更高的版本里，若是實例都是GA(General Availability)狀態，而且版本相同，就能夠從另外一個實例裏面導入表空間文件。不然，被導入的實例則就必須建立文件。

In replication scenarios, innodb_file_per_table must be set to ON on both the master and slave.
在複製場景中，主從都必須把innodb_file_per_table設置成ON。

On Windows, InnoDB stores database, tablespace, and table names internally in lowercase. To avoid import problems on case-sensitive operating systems such as Linux and UNIX, create all databases, tablespaces, and tables using lowercase names. A convenient way to accomplish this is to add the following line to the [mysqld] section of your my.cnf or my.ini file before creating databases, tablespaces, or tables:
在Windows平臺上，InnoDB的數據庫名，表空間名，和表名都是以小寫的形式存儲的。爲了不在Linux和Unix這種區分大小寫平臺上的導入問題，最好全部建立的數據庫名，表空間名，和表名都用小寫。還有一種方便的方式在建立數據庫，表空間和表以前能夠達到這樣的效果，就是是my.cnf或者my.ini配置文件的[mysqld]里加入下面的內容：

[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的時候：

The table is locked in X mode.
表會加X鎖。

The tablespace is detached from the table.
表空間會從表上分離。

When FLUSH TABLES ... FOR EXPORT is run on the source instance:

當在源端運行FLUSH TABLES ... FOR EXPORT的時候：

The table being flushed for export is locked in shared mode.
要導出的表會被刷新的磁盤上，並加共享鎖。

The purge coordinator thread is stopped.
purge協調線程會中止。

Dirty pages are synchronized to disk.
髒數據頁會同步上磁盤上。

Table metadata is written to the binary .cfg file.
表的元數據會寫入到二進制的.cfg文件裏。

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的時候：

The binary .cfg file is deleted.
二進制的.cfg文件被刪除。

The shared lock on the table or tables being imported is released and the purge coordinator thread is restarted.
表上的共享鎖被釋放，重啓purge協調線程。

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的時候，導入算法會爲每一個導入的表空間執行下面的操做：

Each tablespace page is checked for corruption.
每一個表空間的數據頁都會進行損壞檢查。

The space ID and log sequence numbers (LSNs) on each page are updated
每一個數據頁上的space ID and log sequence numbers (LSNs)都會被更新。

Flags are validated and LSN updated for the header page.
數據頁頭的確認標識和LSN會被更新。

Btree pages are updated.
更新Btree數據頁。

The page state is set to dirty so that it will be written to disk.
數據頁的狀態被設置成dirty以即可以被寫入磁盤。

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:

新的特性涉及了下面新的或者重命令的配置參數：

innodb_undo_tablespaces

innodb_undo_directory

innodb_rollback_segments becomes innodb_undo_logs. The old name is still available for compatibility.
innodb_rollback_segments變成了innodb_undo_logs。由於兼容性問題老的名字仍然可用。

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負載的性能基準測試。

6.Periodically increase the value of innodb_undo_logs and rerun performance tests. Find the value where you stop experiencing gains in I/O performance.
按期增長innodb_undo_logs的值並再次進行性能測試，直到找到最適合你的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。