Mysql学习_InnoDB On-Disk Structures_Tablespace

Tablespaces

The System Tablespace:
The InnoDB system tablespace contains the InnoDB data dictionary (metadata for InnoDB-relatedobjects) and is the storage area for the doublewrite buffer, the change buffer, and undo logs. The system tablespace also contains table and index data for user-created tables created in the system tablespace.

The System Tablespace存着InnoDB的数据字典、也是doublewrite buffer, the change buffer,undo logs的存储区域。当然也可以作为表空间存放user-created data and index。

The system tablespace can have one or more data files. By default, one system tablespace data file,named ibdata1, is created in the data directory. The size and number of system tablespace data files is controlled by the innodb_data_file_path startup option.

The System Tablespace可以有一个或多个数据文件，默认为ibdata1。innodb_data_file_path这个参数控制文件的size and number。

相关参数：
innodb_data_file_path：
Dynamic No、Scope Global、Default Value ibdata1:12M:autoextend
File sizes are specified KB, MB or GB (1024MB) by appending K, M or G to the size value. If specifying the data file size in kilobytes (KB), do so in multiples of 1024. Otherwise, KB values are rounded to nearest megabyte (MB) boundary. The sum of the sizes of the files must be at least slightly larger than 12MB.

size可以用K, M or G指定。如果是KB的话，取1024的整数倍，否则会被round到MB,总大小最少要大于12M

A minimum file size is enforced for the first system tablespace data file to ensure that there is enough space for doublewrite buffer pages:
For an innodb_page_size value of 16KB or less, the minimum file size is 3MB.
For an innodb_page_size value of 32KB, the minimum file size is 6MB.
For an innodb_page_size value of 64KB, the minimum file size is 12MB.

为了保证足够的空间for doublewrite buffer pages,第一个 system tablespace data file的大小这么规定：
innodb_page_size<=16KB the minimum file size=3MB、innodb_page_size=32KB the minimum file size=6MB、innodb_page_size=64KB the minimum file size=12MB

The size limit of individual files is determined by your operating system. You can set the file size to more than 4GB on operating systems that support large files. You can also use raw disk partitions as data files.

Size上限取决于操作系统，也可用裸磁盘分区作为数据文件

If you specify the autoextend option, InnoDB extends the data file if it runs out of free space. The autoextend increment is 64MB by default. To modify the increment, change the innodb_autoextend_increment system variable.

如果指定autoextend，文件大小会在剩余空间不足时自增，默认增幅64MB.受innodb_autoextend_increment参数控制

相关参数：
innodb_autoextend_increment：
Dynamic Yes、Scope Global、Default Value 64、Minimum Value 1、Maximum Value 1000
The increment size (in megabytes) for extending the size of an auto-extending InnoDB system tablespace file when it becomes full

The innodb_autoextend_increment setting does not affect file-per-table tablespace files or general tablespace files. These files 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

file-per-table tablespace的自增不受此参数影响，他们的初始自增量很小、之后是4MB

Resizing the System Tablespace：

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.

You can expand the system tablespace by a defined amount by adding another data file:
1.Shut down the MySQL server.
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.
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.
4. Start the MySQL server again.

停服务、如果最近的一个datafile是自增的话、在innodb_data_file_path将其指定成固定大小、在后面再加上新的自增的数据文件、起服务

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.

Decreasing the Size of the InnoDB System Tablespace：
1. Use mysqldump to dump all your InnoDB tables
2. Stop the server.
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.
4. Remove any .frm files for InnoDB tables
5. Configure a new tablespace.
6. Restart the server.
7. Import the dump files.

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.
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.

裸设备分区可以突破操作系统对文件大小的限制、使用裸设备分区要保证运行Mysql server的用户有对分区的读写权限

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.
eg：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.)
3. After InnoDB has initialized the new partition, stop the server, change newraw in the data file specification to raw:
eg：innodb_data_file_path=/dev/hdd1:3Graw;/dev/hdd2:2Graw
4.Restart the server. InnoDB now permits changes to be made.

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.
eg：    innodb_data_file_path=//./D::10Gnewraw、innodb_data_file_path=//./D::10Graw

Windows和Linux and Unix systems 相比，只有参数写法上的区别。

File-Per-Table Tablespaces：
The file-per-table tablespace feature provides a more flexible alternative, where each InnoDB table is stored in its own tablespace data file (.ibd file). This feature is controlled by the innodb_file_per_table configuration option, which is enabled by default.

Advantages：
---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 inthe 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 tablespac 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. In previous releases, you had to move entire database directories to other drives and create symbolic links in the MySQL data directory.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
---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.
---You can copy individual InnoDB tables from one MySQL instance to another (known as 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.
---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. 
---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 file-per-table tablespaces in conjunction with innodb_flush_method.
---The system tablespace stores the data dictionary and undo logs, and is limited in size by InnoDB tablespace size limits. With file-per-table tablespaces, each table has its own tablespace, which provides room for growth.

这么多优势，我用还不行么！

Potential Disadvantages：
---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.
---innodb_file_per_table is enabled by default in MySQL 5.6 and higher. You may consider disabling it if backward compatibility with earlier versions of MySQL is a concern. Disabling innodb_file_per_table prevents table-copying ALTER TABLE operations from implicitly moving a table that resides in the system tablespace to a file-per-table tablespace.
---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 theinnodb_autoextend_increment setting. The initial extensions are by small amounts, after which extensions occur in increments of 4MB.

Enabling File-Per-Table Tablespaces：
The innodb_file_per_table option is enabled by default
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.
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 unless you have explicitly placed the table in file-per-table tablespace or general tablespace using the CREATE TABLE ... TABLESPACE option.

To move a table from the system tablespace to its own tablespace, change the innodb_file_per_table setting and rebuild the table:
mysql> SET GLOBAL innodb_file_per_table=1;
mysql> ALTER TABLE table_name ENGINE=InnoDB;

Tables added to the system tablespace using CREATE TABLE ... TABLESPACE or ALTER TABLE ... TABLESPACE syntax are not affected by the innodb_file_per_table setting. To move these tables from the system tablespace to a file-per-table tablespace, they must be moved explicitly using ALTER TABLE ... TABLESPACE syntax.

General Tablespaces：
A general tablespace is a shared InnoDB tablespace that is created using CREATE TABLESPACE syntax. 
类似于Oracle中的普通表空间

General Tablespace Capabilities：
---Similar to the system tablespace, general tablespaces are shared tablespaces that can store data for multiple tables.
---General tablespaces have a potential memory advantage over file-per-table tablespaces. The server keeps tablespace metadata in memory for the lifetime of a tablespace. Multiple tables in fewer general tablespaces consume less memory for tablespace metadata than the same number of tables in separate file-per-table tablespaces.
---General tablespace data files may be placed in a directory relative to or independent of the MySQL data directory, which provides you with many of the data file and storage management capabilities of file-per-table tablespaces. As with file-per-table tablespaces, the ability to place data files outside of the MySQL data directory allows you to manage performance of critical tables separately, setup RAID or DRBD for specific tables, or bind tables to particular disks, for example.
---General tablespaces support both Antelope and Barracuda file formats, and therefore support all table row formats and associated features. With support for both file formats, general tablespaces have no dependence on innodb_file_format or innodb_file_per_table settings, nor do these variables have any effect on general tablespaces.
---The TABLESPACE option can be used with CREATE TABLE to create tables in a general tablespaces, file-per-table tablespace, or in the system tablespace
---The TABLESPACE option can be used with ALTER TABLE to move tables between general tablespaces, file-per-table tablespaces, and the system tablespace. Previously, it was not possible to move a table from a file-per-table tablespace to the system tablespace. With the general tablespace feature, you can now do so.

Creating a General Tablespace：
A general tablespace can be created in the data directory or outside of it. To avoid conflicts with implicitly created file-per-table tablespaces, creating a general tablespace in a subdirectory under thedata directory is not supported. When creating a general tablespace outside of the data directory, the directory must exist prior to creating the tablespace.

CREATE TABLESPACE tablespace_name ADD DATAFILE 'file_name' [FILE_BLOCK_SIZE = value] [ENGINE [=] engine_name]

An .isl file is created in the MySQL data directory when a general tablespace is created outside of the MySQL data directory.

Adding Tables to a General Tablespace：

CREATE TABLE:
mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY) TABLESPACE ts1;
ALTER TABLE:
mysql> ALTER TABLE t2 TABLESPACE ts1;

General Tablespace Row Format Support：
General tablespaces support all table row formats (REDUNDANT, COMPACT, DYNAMIC, COMPRESSED) with the caveat that compressed and uncompressed tables cannot coexist in the same general tablespace due to different physical page sizes.

For a general tablespace to contain compressed tables (ROW_FORMAT=COMPRESSED),FILE_BLOCK_SIZE must be specified, and the FILE_BLOCK_SIZE value must be a valid compressed page size in relation to the innodb_page_size value
Also, the physical page size of the compressed table (KEY_BLOCK_SIZE) must be equal to FILE_BLOCK_SIZE/1024. For example, if innodb_page_size=16KB and FILE_BLOCK_SIZE=8K, the KEY_BLOCK_SIZE of the table must be 8.

FILE_BLOCK_SIZE values may also be specified in bytes.To determine a valid KEY_BLOCK_SIZE value for a given FILE_BLOCK_SIZE, divide the FILE_BLOCK_SIZE value by 1024. Table compression is not support for 32K and 64K InnoDB page sizes. 
If you do not specify FILE_BLOCK_SIZE when creating a general tablespace, FILE_BLOCK_SIZE defaults to innodb_page_size. When FILE_BLOCK_SIZE is equal to innodb_page_size, the tablespace may only contain tables with an uncompressed row format (COMPACT, REDUNDANT, and DYNAMIC row formats).

Moving Tables Between Tablespaces Using ALTER TABLE：
1.move to general tablespaces
    ALTER TABLE tbl_name TABLESPACE [=] tablespace_name;
2.move to system tablespace
    ALTER TABLE tbl_name TABLESPACE [=] innodb_system;
3.move to a file-per-table tablespace
    ALTER TABLE tbl_name TABLESPACE [=] innodb_file_per_table;
    
ALTER TABLE ... TABLESPACE operations always cause a full table rebuild, even if the TABLESPACE attribute has not changed from its previous value.
ALTER TABLE ... TABLESPACE syntax does not support moving a table from a temporary tablespace to a persistent tablespace.

ALTER TABLE ... TABLESPACE操作相当于全表重建 即使TABLESPACE属性没变化，且不支持从临时表空间转移到永久表空间。

Dropping a General Tablespace：
The DROP TABLESPACE statement is used to drop an InnoDB general tablespace.
All tables must be dropped from the tablespace prior to a DROP TABLESPACE operation. If the tablespace is not empty, DROP TABLESPACE returns an error.

DROP TABLESPACE适用于general tablespace，drop tablespace必须保证tablespace是空的，里面的表都必须先被删除，否则的话DROP TABLESPACE会报错

A general tablespace does not belong to any particular database. A DROP DATABASE operation can drop tables that belong to a general tablespace but it cannot drop the tablespace, even if the DROP DATABASE operation drops all tables that belong to the tablespace. A general tablespace must be dropped explicitly using DROP TABLESPACE tablespace_name.
general tablespace独立于database，drop database对general tablespace没有影响，它只能通过drop tablespace删除

tablespace_name is a case-sensitive identifier in MySQL.
tablespace_name区分大小写

General Tablespace Limitations：
1.A generated or existing tablespace cannot be changed to a general tablespace.
2.Creation of temporary general tablespaces is not supported.
3.General tablespaces do not support temporary tables.
4.Tables stored in a general tablespace may only be opened in MySQL releases that support general tablespaces.
5.Similar to the system tablespace, truncating or dropping tables stored in a general tablespace creates free space internally in the general tablespace .ibd data file which can only be used for new InnoDB data. Space is not released back to the operating system as it is for file-per-table tablespaces.
6.ALTER TABLE ... DISCARD TABLESPACE and ALTER TABLE ...IMPORT TABLESPACE are not supported for tables that belong to a general tablespace.
7.Support for placing table partitions in general tablespaces was deprecated in MySQL 5.7.24 and will be removed in a future MySQL version.

Undo Tablespaces:

Undo tablespaces contain undo logs, which are collections of undo log records that contain information about how to undo the latest change by a transaction to a clustered index record.
Undo logs exist within undo log segments, which are contained within rollback segments. 
The innodb_rollback_segments variable defines the number of rollback segments allocated to each undo tablespace.

The number of undo tablespaces used by InnoDB is controlled by the innodb_undo_tablespaces configuration option. This option can only be configured when initializing the MySQL instance. It cannot be changed afterward.

相关参数：
innodb_rollback_segments：
Dynamic Yes、Scope Global、Default Value 128、Minimum Value 1、Maximum Value 128
Defines the number of rollback segments used by InnoDB for transactions that generate undo records. The number of transactions that each rollback segment supports depends on the InnoDB page size and the number of undo logs assigned to each transaction. 
One rollback segment is always assigned to the system tablespace, and 32 rollback segments are reserved for use by temporary tables and reside in the temporary tablespace (ibtmp1). To allocate additional rollback segment, innodb_rollback_segments must be set to a value greater than 33.
If you configure separate undo tablespaces, the rollback segment in the system tablespace is rendered inactive.

When innodb_rollback_segments is set to 32 or less, InnoDB assigns one rollback segment to the system tablespace and 32 to the temporary tablespace.

When innodb_rollback_segments is set to a value greater than 32, InnoDB assigns one rollback segment to the system tablespace, 32 to the temporary tablespace, and additional rollback segments to undo tablespaces, if present. 
If undo tablespaces are not present, additional rollback segments are assigned to the system tablespace.

innodb_undo_tablespaces：
Dynamic No、Scope Global、Default Value 0、Minimum Value 0、Maximum Value (>= 5.7.8) 95、Maximum Value (<= 5.7.7) 126
The number of undo tablespaces used by InnoDB. The default value is 0.
The innodb_undo_tablespaces configuration option is deprecated and will be removed in a future release.

Configuring Undo Tablespaces：
1. Specify a directory location for undo tablespaces using the innodb_undo_directory configuration option. If a directory location is not specified, undo tablespaces are created in the data directory.
2. Define the number of rollback segments using the innodb_rollback_segments configuration option. Start with a relatively low value and increase it incrementally over time to examine the effect on performance. The default setting for innodb_rollback_segments is 128, which is also the maximum value.
3. Define the number of undo tablespaces using the innodb_undo_tablespaces option. The specified number of undo tablespaces is fixed for the life of the MySQL instance, so if you are uncertain about an optimal value, estimate on the high side.
4. Create a new MySQL test instance using the option values you have chosen.
5. Use a realistic workload on your test instance with data volume similar to your production servers to test the configuration.
6. Benchmark the performance of I/O intensive workloads.
7. Periodically increase the value of innodb_rollback_segments and rerun performance tests until there are no further improvements in I/O performance.

相关参数：
innodb_undo_directory：
Dynamic No、Scope Global、Default Value ./
The path where InnoDB creates undo tablespaces. Typically used to place undo logs on a different storage device.
There is no default value (it is NULL). If a path is not specified, undo tablespaces are created in the MySQL data directory, as defined by datadir.

Truncating Undo Tablespaces：
Truncating undo tablespaces requires that the MySQL instance have a minimum of two active undo tablespaces, which ensures that one undo tablespace remains active while the other is taken offline to be truncated. 
The number of undo tablespaces is defined by the innodb_undo_tablespaces variable. The default value is 0. 

To have undo tablespaces truncated, enable the innodb_undo_log_truncate variable.

When the innodb_undo_log_truncate variable is enabled, undo tablespaces that exceed the size limit defined by the innodb_max_undo_log_size variable are subject to truncation. The innodb_max_undo_log_size variable is dynamic and has a default value of 1073741824 bytes (1024 MiB)

When the innodb_undo_log_truncate variable is enabled:
1.Undo tablespaces that exceed the innodb_max_undo_log_size setting are marked for truncation. Selection of an undo tablespace for truncation is performed in a circular fashion to avoid truncating the same undo tablespace each time.
2.Rollback segments residing in the selected undo tablespace are made inactive so that they are not assigned to new transactions. Existing transactions that are currently using rollback segments are permitted to finish.
3.The purge system frees rollback segments that are no longer in use.
4. After all rollback segments in the undo tablespace are freed, the truncate operation runs and truncates the undo tablespace to its initial size. The initial size of an undo tablespace depends on the innodb_page_size value. 
For the default 16KB page size, the initial undo tablespace file size is 10MiB. For 4KB, 8KB, 32KB, and 64KB page sizes, the initial undo tablespace files sizes are 7MiB, 8MiB, 20MiB, and 40MiB, respectively.
The size of an undo tablespace after a truncate operation may be larger than the initial size due to immediate use following the completion of the operation.
5.Rollback segments are reactivated so that they can be assigned to new transactions.

相关参数：
innodb_max_undo_log_size：
Dynamic Yes、Scope Global、Default Value 1G、Minimum Value 10M、Maximum Value 2**64-1
Defines a threshold size for undo tablespaces. If an undo tablespace exceeds the threshold, it can be marked for truncation when innodb_undo_log_truncate is enabled. 

innodb_undo_log_truncate:
Dynamic Yes、Scope Global、Default Value OFF
When enabled, undo tablespaces that exceed the threshold value defined by innodb_max_undo_log_size are marked for truncation. Only undo tablespaces can be truncated.
Truncating undo logs that reside in the system tablespace is not supported. 
For truncation to occur,there must be at least two undo tablespaces and two redo-enabled undo logs configured to use undo tablespaces. This means that innodb_undo_tablespaces must be set to a value equal to or greater than 2, and innodb_rollback_segments must set to a value equal to or greater than 35.

Expediting Truncation of Undo Tablespaces：
The purge thread is responsible for emptying and truncating undo tablespaces. By default, the purge thread looks for undo tablespaces to truncate once every 128 times that purge is invoked. 
The frequency with which the purge thread looks for undo tablespaces to truncate is controlled by the innodb_purge_rseg_truncate_frequency variable, which has a default setting of 128.

When the purge thread finds an undo tablespace that requires truncation, the purge thread returns with increased frequency to quickly empty and truncate the undo tablespace.

相关参数：
innodb_purge_rseg_truncate_frequency：
Dynamic Yes、Scope Global、Default Value 128、Minimum Value 1、Maximum Value 128
Defines the frequency with which the purge system frees rollback segments in terms of the number of times that purge is invoked.

Performance Impact of Truncating Undo Tablespace Files：
When an undo tablespace is truncated, the rollback segments in the undo tablespace are deactivated.The active rollback segments in other undo tablespaces assume responsibility for the entire system load, which may result in a slight performance degradation. 
The amount of performance degradation depends on a number of factors:
Number of undo tablespaces、Number of undo logs、Undo tablespace size、Speed of the I/O susbsystem、Existing long running transactions、System load
The easiest way to avoid impacting performance when truncating undo tablepaces is to increase the number of undo tablespaces.

The Temporary Tablespace：
Non-compressed, user-created temporary tables and on-disk internal temporary tables are created in a shared temporary tablespace. 
The innodb_temp_data_file_path configuration option defines the relative path, name, size, and attributes for temporary tablespace data files. 
If no value is specified for innodb_temp_data_file_path, the default behavior is to create an auto-extending data file named ibtmp1 in the innodb_data_home_dir directory that is slightly larger than 12MB.

Note:
In MySQL 5.6, non-compressed temporary tables are created in individual file-per-table tablespaces in the temporary file directory, or in the InnoDB system tablespace in the data directory if innodb_file_per_table is disabled.
The introduction of a shared temporary tablespace in MySQL 5.7 removes performance costs associated with creating and removing a file-per-table tablespace for each temporary table. A dedicated temporary tablespace also means that it is no longer necessary to save temporary table metadata to the InnoDB system tables.

Compressed temporary tables, which are temporary tables created using the ROW_FORMAT=COMPRESSED attribute, are created in file-per-table tablespaces in the temporary file directory.

The temporary tablespace is removed on normal shutdown or on an aborted initialization, and is recreated each time the server is started. The temporary tablespace receives a dynamically generated space ID when it is created. Startup is refused if the temporary tablespace cannot be created. 
The temporary tablespace is not removed if the server halts unexpectedly. In this case, a database administrator can remove the temporary tablespace manually or restart the server, which removes and recreates the temporary tablespace automatically.

The temporary tablespace cannot reside on a raw device.

INFORMATION_SCHEMA.FILES provides metadata about the InnoDB temporary tablespace. Issue a query similar to this one to view temporary tablespace metadata:

mysql> SELECT * FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME='innodb_temporary'\G;

INFORMATION_SCHEMA.INNODB_TEMP_TABLE_INFO provides metadata about user-created temporary tables that are currently active within an InnoDB instance.

相关参数：
innodb_temp_data_file_path(类似于innodb_data_file_path)：
Dynamic No、Scope Global、Introduced 5.7.1、Default Value ibtmp1:12M:autoextend
Defines the relative path, name, size, and attributes of InnoDB temporary tablespace data files.If you do not specify a value for innodb_temp_data_file_path, the default behavior is to create a single, auto-extending data file named ibtmp1 in the MySQL data directory. TThe initial file size is slightly larger than 12MB.
The temporary tablespace data file cannot have the same name as another InnoDB data file. Any inability or error creating a temporary tablespace data file is treated as fatal and server startup is refused. The temporary tablespace has a dynamically generated space ID, which can change on each server restart.

File sizes are specified KB, MB or GB (1024MB) by appending K, M or G to the size value. The sum of the sizes of the files must be slightly larger than 12MB.

The size limit of individual files is determined by your operating system. You can set the file size to more than 4GB on operating systems that support large files. Use of raw disk partitions for temporary tablespace data files is not supported.

The autoextend and max attributes can be used only for the data file that is specified last in the innodb_temp_data_file_path setting. 

If you specify the autoextend option, InnoDB extends the data file if it runs out of free space. The autoextend increment is 64MB by default. To modify the increment, change the innodb_autoextend_increment system variable.

The full directory path for temporary tablespace data files is formed by concatenating the paths defined by innodb_data_home_dir and innodb_temp_data_file_path.

The temporary tablespace is shared by all non-compressed InnoDB temporary tables. Compressed temporary tables reside in file-per-table tablespace files created in the temporary file directory, which is defined by the tmpdir configuration option

innodb_data_home_dir：
Dynamic No、Scope Global
The common part of the directory path for InnoDB system tablespace data files. This setting does not affect the location of file-per-table tablespaces when innodb_file_per_table is enabled.
The default value is the MySQL data directory. If you specify the value as an empty string, you can specify an absolute file paths for innodb_data_file_path.

Managing Temporary Tablespace Data File Size:
An autoextending temporary tablespace data file can become large in environments that use large temporary tables or that use temporary tables extensively. A large data file can also result from long running queries that use temporary tables.
To check the size of temporary tablespace data files, query the INFORMATION_SCHEMA.FILES table using a query similar to this:

mysql> SELECT FILE_NAME, TABLESPACE_NAME, ENGINE, INITIAL_SIZE, TOTAL_EXTENTS*EXTENT_SIZE AS TotalSizeBytes, DATA_FREE, MAXIMUM_SIZE FROM INFORMATION_SCHEMA.FILES WHERE TABLESPACE_NAME = 'innodb_temporary'\G;

The TotalSizeBytes value reports the current size of the temporary tablespace data file.

Alternatively, check the temporary tablespace data file size on your operating system.

When the data file reaches the maximum size, queries fail with an error indicating that the table is full.Configuring innodb_temp_data_file_path requires restarting the server.
Alternatively, configure the default_tmp_storage_engine and internal_tmp_disk_storage_engine options, which define the storage engine to use for user-created and on-disk internal temporary tables, respectively. Both options are set to InnoDB by default.
The MyISAM storage engine uses an individual file for each temporary table, which is removed when the temporary table is dropped.

Creating a Tablespace Outside of the Data Directory:
The CREATE TABLE ... DATA DIRECTORY clause permits creating a file-per-table tablespace outside of the data directory.
Be sure of the location that you choose. The DATA DIRECTORY clause cannot be used with ALTER TABLE to change the location later.
The tablespace data file is created in the specified directory, within in a subdirectory named for the schema to which the table belongs. 
An isl file file that contains the tablespace path is created in the schema directory, beneath the data directory. The isl file is treated like a symbolic link.
The following example demonstrates creating a file-per-table tablespace outside of the data directory. It is assumed that the innodb_file_per_table variable is enabled.

mysql> create table tab_tsp1 (table_name varchar(50)) data directory='/u01/mysqldata';
Query OK, 0 rows affected (0.12 sec)

CREATE TABLE ... TABLESPACE syntax can also be used in combination with the DATA DIRECTORY clause to create a file-per-table tablespace outside of the data directory. To do so, specify innodb_file_per_table as the tablespace name.
The innodb_file_per_table variable does not need to be enabled when using this method.

mysql> create table tab_tsp1 (table_name varchar(50)) data directory='/u01/mysqldata' TABLESPACE = innodb_file_per_table;
Query OK, 0 rows affected (0.12 sec)

Attempting to access a table when the associated tablespace data file is missing causes a serious error that requires a server restart.
A server restart might fail if the tablespace data file file is not at the expected path. In this case,manually remove the isl file from the schema directory, and after restarting, drop the table to remove the .frm file and the information about the table from the data dictionary.

Copying Tablespaces to Another Instance:

Limitations and Usage Notes:
1.The tablespace copy procedure is only possible when innodb_file_per_table is set to ON,which is the default setting. Tables residing in the shared system tablespace cannot be quiesced.
2.When a table is quiesced, only read-only transactions are allowed on the affected table.
3.When importing a tablespace, the page size must match the page size of the importing instance.
4.DISCARD TABLESPACE is not supported for tablespaces with a parent-child (primary key-foreignkey) relationship when foreign_key_checks is set to 1. Before discarding a tablespace for parent-child tables, set foreign_key_checks=0. Partitioned InnoDB tables do not support foreign keys.
5.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. Partitioned InnoDB tables do not support foreign keys.
6.ALTER TABLE ... IMPORT TABLESPACE and ALTER TABLE ... IMPORT PARTITION ...TABLESPACE do not require a .cfg metadata file to import a tablespace. However, metadata checks are not performed when importing without a .cfg file。
7.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.
8.Due to a .cfg metadata file limitation, schema mismatches are not reported for partition type or partition definition differences when importing tablespace files for partitioned tables. Column differences are reported.
9.Importing a tablespace file from another MySQL server instance works if both instances have GA(General Availability) status and their versions are within the same series. Otherwise, the file must have been created on the same server instance into which it is imported.
10.In replication scenarios, innodb_file_per_table must be set to ON on both the master and slave.
11.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. 
12.ALTER TABLE ... DISCARD TABLESPACE and ALTER TABLE ...IMPORT TABLESPACE are not supported with tables that belong to an InnoDB general tablespace. 
13.The default row format for InnoDB tables is configurable using the innodb_default_row_format configuration option. Attempting to import a table that does not explicitly define a row format (ROW_FORMAT), or that uses ROW_FORMAT=DEFAULT, could result in a schema mismatch error if the innodb_default_row_format setting on the source instance differs from the setting on the destination instance.
14.When exporting a tablespace that is encrypted using the InnoDB tablespace encryption feature,InnoDB generates a .cfp file in addition to a .cfg metadata file. The .cfp file must be copied to the destination instance together with the .cfg file and tablespace file before performing the ALTER TABLE ... IMPORT TABLESPACE operation on the destination instance. The .cfp file contains a transfer key and an encrypted tablespace key. On import, InnoDB uses the transfer key to decrypt the tablespace key
15.FLUSH TABLES ... FOR EXPORT is not supported on tables that have a FULLTEXT index. Full-text search auxiliary tables are not flushed. After importing a table with a FULLTEXT index, run OPTIMIZE TABLE to rebuild the FULLTEXT indexes. Alternatively, drop FULLTEXT indexes before the export operation and recreate them after importing the table on the destination instance.

Example 1: Copying an InnoDB Table to Another Instance
1.On the source instance, create a table if one does not exist:

mysql> USE test;
mysql> CREATE TABLE t(c1 INT) ENGINE=InnoDB;

2.On the destination instance, create a table if one does not exist:

mysql> USE test;
mysql> CREATE TABLE t(c1 INT) ENGINE=InnoDB;

3.On the destination instance, discard the existing tablespace. (Before a tablespace can be imported,InnoDB must discard the tablespace that is attached to the receiving table.)

mysql> ALTER TABLE t DISCARD TABLESPACE;

4.On the source instance, run FLUSH TABLES ... FOR EXPORT to quiesce the table and create the .cfg metadata file(The metadata (.cfg) is created in the InnoDB data directory):

mysql> USE test;
mysql> FLUSH TABLES t FOR EXPORT;

5.Copy the .ibd file and .cfg metadata file from the source instance to the destination instance. For example:

shell> scp /path/to/datadir/test/t.{ibd,cfg} destination-server:/path/to/datadir/test

6.On the source instance, use UNLOCK TABLES to release the locks acquired by FLUSH TABLES ... FOR EXPORT:

mysql> USE test;
mysql> UNLOCK TABLES;

7.On the destination instance, import the tablespace:

mysql> USE test;
mysql> ALTER TABLE t IMPORT TABLESPACE;

Example 2: Copying an InnoDB Partitioned Table to Another Instance
1.On the source instance, create a partitioned table if one does not exist. In the following example, a table with three partitions (p0, p1, p2) is created:

mysql> USE test;
mysql> CREATE TABLE t1 (i int) ENGINE = InnoDB PARTITION BY KEY (i) PARTITIONS 3;

2.On the destination instance, create the same partitioned table:

mysql> USE test;
mysql> CREATE TABLE t1 (i int) ENGINE = InnoDB PARTITION BY KEY (i) PARTITIONS 3;

3.On the destination instance, discard the tablespace for the partitioned table. (Before the tablespace can be imported on the destination instance, the tablespace that is attached to the receiving table must be discarded.)

mysql> ALTER TABLE t1 DISCARD TABLESPACE;

The three .ibd files that make up the tablespace for the partitioned table are discarded from the /datadir/test directory

4.On the source instance, run FLUSH TABLES ... FOR EXPORT to quiesce the partitioned table and create the .cfg metadata files:

mysql> USE test;
mysql> FLUSH TABLES t1 FOR EXPORT;

5.Copy the .ibd and .cfg files from the source instance database directory to the destination instance database directory. For example:

shell>scp /path/to/datadir/test/t1*.{ibd,cfg} destination-server:/path/to/datadir/test

6. On the source instance, use UNLOCK TABLES to release the locks acquired by FLUSH TABLES ... FOR EXPORT:

mysql> USE test;
mysql> UNLOCK TABLES;

7. On the destination instance, import the tablespace for the partitioned table:

mysql> USE test;
mysql> ALTER TABLE t1 IMPORT TABLESPACE;

Example 3: Copying InnoDB Table Partitions to Another Instance:
1.On the source instance, create a partitioned table if one does not exist. In the following example, a table with four partitions (p0, p1, p2, p3) is created:

mysql> USE test;
mysql> CREATE TABLE t1 (i int) ENGINE = InnoDB PARTITION BY KEY (i) PARTITIONS 4;

2.On the destination instance, create the same partitioned table:

mysql> USE test;
mysql> CREATE TABLE t1 (i int) ENGINE = InnoDB PARTITION BY KEY (i) PARTITIONS 4;

3.On the destination instance, discard the tablespace partitions that you plan to import from the source instance. (Before tablespace partitions can be imported on the destination instance, the corresponding partitions that are attached to the receiving table must be discarded.)

mysql> ALTER TABLE t1 DISCARD PARTITION p2, p3 TABLESPACE;

4.On the source instance, run FLUSH TABLES ... FOR EXPORT to quiesce the partitioned table and create the .cfg metadata files.

mysql> USE test;
mysql> FLUSH TABLES t1 FOR EXPORT;

5.Copy the .ibd and .cfg files from the source instance database directory to the destination instance database directory. 
In this example, only the .ibd and .cfg files for partition 2 (p2) and partition 3 (p3) are copied to the data directory on the destination instance. Partition 0 (p0) and partition 1 (p1) remain on the source instance.

shell> scp t1#P#p2.ibd t1#P#p2.cfg t1#P#p3.ibd t1#P#p3.cfg destination-server:/path/to/datadir/test

6.On the source instance, use UNLOCK TABLES to release the locks acquired by FLUSHTABLES ... FOR EXPORT:

mysql> USE test;
mysql> UNLOCK TABLES;

7. On the destination instance, import the tablespace partitions (p2 and p3):

mysql> USE test;
mysql> ALTER TABLE t1 IMPORT PARTITION p2, p3 TABLESPACE;

Transportable Tablespace Internals

The following information describes internals and error log messaging for the transportable tablespaces copy procedure for a regular InnoDB table.
When ALTER TABLE ... DISCARD TABLESPACE is run on the destination instance:
    The table is locked in X mode.
    The tablespace is detached from the table.
    
When FLUSH TABLES ... FOR EXPORT is run on the source instance:
    The table being flushed for export is locked in shared mode.
    The purge coordinator thread is stopped.
    Dirty pages are synchronized to disk.
    Table metadata is written to the binary .cfg file.
    
When UNLOCK TABLES is run on the source instance:
    The binary .cfg file is deleted.
    The shared lock on the table or tables being imported is released and the purge coordinator thread is restarted.
    
When ALTER TABLE ... IMPORT TABLESPACE is run on the destination instance, the import algorithm performs the following operations for each tablespace being imported:
    Each tablespace page is checked for corruption.
    The space ID and log sequence numbers (LSNs) on each page are updated
    Flags are validated and LSN updated for the header page.
    Btree pages are updated.
    The page state is set to dirty so that it is written to disk.
    
    
InnoDB Tablespace Encryption:

1.Encryption is only supported for file-per-table tablespaces. 
2.Advanced Encryption Standard (AES) is the only supported encryption algorithm. InnoDB tablespace encryption uses Electronic Codebook (ECB) block encryption mode for tablespace key encryption and Cipher Block Chaining (CBC) block encryption mode for data encryption.
3.Altering the ENCRYPTION attribute of a table is performed using the COPY algorithm. The INPLACE algorithm is not supported.
4.You cannot move or copy a table from an encrypted file-per-table tablespace to a tablespace type that does not support encryption.
5.Tablespace encryption only applies to data in the tablespace. Data is not encrypted in the redo log,undo log, or binary log.
6.It is not permitted to change the storage engine of a table that resides or previously resided in an encrypted tablespace.