14.7.4 InnoDB File-Per-Table Tablespaces InnoDB

14.7.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 tablespace特性提供了一個更靈活的替代方案，其中每個InnoDB表及其索引存儲在一個單獨的.ibd數據文件中。每個這樣的.ibd數據文件表示一個單獨的表空間。這個特性由innodb_file_per_table配置選項控制，在MySQL 5.6.6或更高版本中默認啓用該選項。
Advantages of File-Per-Table Tablespaces

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 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.
• 在截斷或刪除存儲在 file-per-table表空間中的表時，可以回收磁盤空間。截斷或刪除存儲在共享系統表空間中的表將在系統表空間數據文件（ibdata文件）的內部創建空閒空間，這些文件只能用於新的InnoDB數據。
• 類似地，位於共享表空間中的表複製ALTER TABLE操作可以增加表空間使用的空間量。這些操作可能需要與表中的數據和索引一樣多的額外空間。表複製ALTER TABLE操作所需的額外空間不會像 file-per-table表空間一樣釋放回操作系統。
• 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.3, “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.7.5, “Creating File-Per-Table Tablespaces Outside the Data Directory”.
• 您可以將特定表存儲在單獨的存儲設備上，用於I/O優化，空間管理或備份目的。在以前的版本中，您必須將整個數據庫目錄移動到其他驅動器並在MySQL數據目錄中創建符號鏈接，詳細描述請看Section 8.12.3, “Using Symbolic Links”.在MySQL 5.6.6及更高版本中，您可以使用語法CREATE TABLE ... DATA DIRECTORY = absolute_path_to_directory指定每個表的位置，更多解釋請看Section 14.7.5, “Creating File-Per-Table Tablespaces 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文件，僅使用存儲實際數據所需的空間。優化完成後，InnoDB將刪除舊的.ibd文件並將其替換爲新的.ibd文件。如果以前的.ibd文件顯着增長，但實際數據僅佔其大小的一部分，則運行OPTIMIZE TABLE可以回收未使用的空間。
• You can move individual InnoDB tables rather than entire databases.
• 您可以移動單獨的InnoDB表而不是整個數據庫。
• You can copy individual InnoDB tables from one MySQL instance to another (known as the transportable tablespace feature).
• 您可以將單個InnoDB表從一個MySQL實例複製到另一個（稱爲transportable tablespace功能）。
• 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.
• file-per-table表空間創建的表使用Barracuda文件格式。Barracuda文件格式支持壓縮和動態行格式等特性。
• You can enable more efficient storage for tables with large BLOB or TEXT columns using the 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.
• 當發生損壞，服務器無法重啓或備份和二進制日誌不可用時，File-per-table 表空間可以提高成功恢復的機會。
• 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文件系統不允許對單個文件進行併發寫操作。因此，在將innodb_flush_method與file-per-tableb表空間結合使用時，性能可能得到改進。
• The system tablespace stores the data dictionary and undo logs, and is limited in size by InnoDB tablespace size limits. See Section 14.8.1.7, “Limits on InnoDB Tables”. With file-per-table tablespaces, each table has its own tablespace, which provides room for growth.
• 系統表空間存儲數據字典和undo logs,，並且受InnoDB表空間大小限制的限制。更多信息請看 Section 14.8.1.7, “Limits on InnoDB Tables”。通過file-per-tableb表空間,，每個表都有其自己的表空間，這爲增長提供了空間。

Potential Disadvantages of File-Per-Table Tablespaces

File-Per-Table 表空間的潛在缺點

* 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必須爲每個表保留一個打開的文件句柄，如果有多個表在file-per-table表空間中，那麼這可能會影響性能。
* More file descriptors are used.
* 使用更多的文件描述符。
* 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).

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. This behavior also does not apply to tables added to the system tablespace using CREATE TABLE ... TABLESPACE or ALTER TABLE ... TABLESPACE syntax. These tables are not affected by the innodb_file_per_table setting.

• Innodb_file_per_table默認在MySQL 5.6.6及更高版本中啓用。 如果向後兼容MySQL 5.5或5.1，你可以考慮禁用它。在ALTER TABLE重新創建表（ALGORITHM = COPY）的情況下，禁用innodb_file_per_table會阻止ALTER TABLE將InnoDB表從系統表空間移動到單個.ibd文件。
• 例如，在重構InnoDB表的聚簇索引時，將使用innodb_file_per_table的當前設置重新創建該表。添加或刪除InnoDB輔助索引時，此行爲不適用。如果在不重建表的情況下創建輔助索引，則不管當前的innodb_file_per_table設置如何，索引都將存儲在與表數據相同的文件中。此行爲也不適用於使用CREATE TABLE ... TABLESPACE或ALTER TABLE ... TABLESPACE語法添加到系統表空間的表。 這些表不受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和表掃描性能。 但是，當管理碎片時，將文件放在其自己的表空間中可以提高性能
• 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表空間時會掃描緩衝池，這對於數十GB的緩衝池可能需要幾秒鐘的時間。描採用廣泛的內部鎖執行，這可能會延遲其他操作。 系統表空間中的表不受影響。
• 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變量定義了用於在自動擴展共享表空間文件變滿時擴展大小的增量大小（以MB爲單位），該變量不適用於file-per-table 表空間文件，該文件是自動擴展的，而不管 innodb_autoextend_increment設置。 最初的擴展是少量的，之後擴展以4MB爲增量進行。