file-per-table 表空间包含单个
InnoDB
表的数据和索引,并存储在文件系统中的单个数据文件中。
File-per-table 表空间特征在本节的以下主题下进行了描述:
InnoDB
默认情况下在 file-per-table 表空间中创建表。此行为由
innodb_file_per_table
变量控制。禁用innodb_file_per_table
会导致InnoDB
在系统表空间中创建表。
可以在选项文件中指定innodb_file_per_table
设置,也可以在运行时使用
SET
GLOBAL
语句配置设置。在运行时更改设置需要足够的权限来设置全局系统变量。请参阅第 5.1.8.1 节,“系统变量权限”。
选项文件:
[mysqld]
innodb_file_per_table=ON
SET
GLOBAL
在运行时
使用:
mysql> SET GLOBAL innodb_file_per_table=ON;
innodb_file_per_table
在 MySQL 5.6 及更高版本中默认启用。如果担心与早期版本的 MySQL 的向后兼容性,您可以考虑禁用它。
禁用
innodb_file_per_table
可防止表复制ALTER
TABLE
操作隐式地将驻留在系统表空间中的表移动到 file-per-table 表空间。表复制ALTER
TABLE
操作使用当前innodb_file_per_table
设置重新创建表。此行为不适用于添加或删除二级索引时,也不适用于
ALTER TABLE
使用该INPLACE
算法的操作。
一个 file-per-table 表空间是在
.ibd
MySQL 数据目录下的模式目录中的数据文件中创建的。该.ibd
文件以表 (
) 命名。例如,表的数据文件table_name
.ibdtest.t1
创建在test
MySQL数据目录下的目录中:
mysql> USE test;
mysql> CREATE TABLE t1 (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100)
) ENGINE = InnoDB;
$> cd /path/to/mysql/data/test
$> ls
t1.ibd
您可以使用该语句的DATA DIRECTORY
子句
CREATE TABLE
在数据目录之外隐式创建一个 file-per-table 表空间数据文件。有关详细信息,请参阅
第 14.6.1.2 节,“在外部创建表”。
File-per-table 表空间与共享系统表空间相比具有以下优点。
在截断或删除在 file-per-table 表空间中创建的表后,磁盘空间将返回给操作系统。截断或删除存储在系统表空间中的表会在系统表空间内创建只能用于
InnoDB
数据的可用空间。换句话说,在表被截断或删除后,系统表空间的大小不会缩小。对驻留在系统表空间中的表执行表复制
ALTER TABLE
操作会增加表空间占用的磁盘空间量。此类操作可能需要与表中的数据加上索引一样多的额外空间。该空间不会像每个表的文件表空间那样释放回操作系统。TRUNCATE TABLE
在驻留在 file-per-table 表空间中的表上执行时性能更好。File-per-table 表空间数据文件可以在单独的存储设备上创建,用于 I/O 优化、空间管理或备份目的。请参阅 第 14.6.1.2 节,“在外部创建表”。
您可以从另一个 MySQL 实例导入驻留在 file-per-table 表空间中的表。请参阅 第 14.6.1.3 节,“导入 InnoDB 表”。
在 file-per-table 表空间中创建的表使用 Barracuda 文件格式。请参阅 第 14.10 节,“InnoDB 文件格式管理”。
DYNAMIC
Barracuda 文件格式启用与COMPRESSED
行格式关联的功能 。请参阅第 14.11 节,“InnoDB 行格式”。存储在单个表空间数据文件中的表可以节省时间并提高在发生数据损坏、备份或二进制日志不可用或无法重新启动 MySQL 服务器实例时成功恢复的机会。
在 file-per-table 表空间中创建的表可以使用 MySQL Enterprise Backup 快速备份或恢复,而不会中断其他
InnoDB
表的使用。这对于备份计划不同或需要备份频率较低的表是有益的。有关详细信息,请参阅制作部分备份。File-per-table 表空间允许通过监视表空间数据文件的大小来监视文件系统上的表大小。
innodb_flush_method
当设置为 时,常见的 Linux 文件系统不允许并发写入单个文件,例如系统表空间数据文件O_DIRECT
。因此,将 file-per-table 表空间与此设置结合使用时可能会提高性能。包含数据字典和撤消日志等其他结构的共享系统表空间中的表
InnoDB
的大小受到 64TB 表空间大小限制的限制。相比之下,每个 file-per-table 表空间的大小限制为 64TB,这为单个表的大小增长提供了充足的空间。
与共享系统表空间相比,File-per-table 表空间具有以下缺点。
使用 file-per-table 表空间,每个表可能有未使用的空间,只能由同一个表的行使用,如果管理不当,可能会导致空间浪费。
fsync
操作是在多个 file-per-table 数据文件而不是共享系统表空间数据文件上执行的。因为fsync
操作是针对每个文件的,所以不能合并多个表的写操作,这会导致fsync
操作总数增加。mysqld必须为每个 file-per-table 表空间保留一个打开的文件句柄,如果在 file-per-table 表空间中有许多表,这可能会影响性能。
当每个表都有自己的数据文件时,需要更多的文件描述符。
可能会出现更多碎片,这会影响
DROP TABLE
表扫描性能。但是,如果碎片得到管理,每个表的文件表空间可以提高这些操作的性能。删除驻留在 file-per-table 表空间中的表时会扫描缓冲池,这对于大型缓冲池可能需要几秒钟。扫描是使用广泛的内部锁执行的,这可能会延迟其他操作。
该
innodb_autoextend_increment
变量定义了当自动扩展系统表空间文件变满时用于扩展其大小的增量大小,不适用于 file-per-table 表空间文件,无论innodb_autoextend_increment
设置如何,这些文件都是自动扩展的。最初的 file-per-table 表空间扩展是少量的,之后扩展以 4MB 的增量出现。