14.5.4 InnoDB File-Per-Table Tablespaces 每个表一个文件

14.5.4 InnoDB File-Per-Table Tablespaces   每个表一个文件

从历史上看, 所有的InnoDB 表和索引是存储在system 表空间,

这个整体的方法是针对机器专注于数据库处理,精心策划的数据增长,

任何磁盘存储分配给MySQL 不会用于其他目的。

InnoDB的 file-per-table 表空间功能提供一个更加灵活的选择,

每个InnoDB 表和它的索引是是单独存储.ibd数据文件。

每个.ibd 数据文件代表一个单独的表空间,这个功能是有innodb_file_per_table 配置选项控制,

在MySQL 5.6.6和更高版本默认启用的。

 File-Per-Table  表空间的优势:

1. 你可以回收磁盘空间当runcate或者drop 一个存储在file-per-table tablepace的表。

 Truncating or dropping  存储在共享系统表空间的表内部的创建空闲空间 在system tablespace data files

(ibdata files)  ,空闲的空间只能用于新的InnoDB 数据

同样， 一个表复制ALTER TABLE 操作食欲一个共享的表空间可以增加属于表空间的总量。

这样的操作可能需要更多额外的空间作为数据在表加上索引。

额外的空间用于table-copying ALTER TABLE 选项不会释放回操作系统

2. TRUNCATE TABLE 选项是更快的 当运行在存储在file-per-table tablepaces的表

3.你可以存储特定的包在单独的存储设备,对于I/O优化,空间管理,

或者备份目的。在以前的版本中,你需要移动整个数据库目录到其他设备,然后创建符号连接

在MySQL 数据目录，

在MySQL 5.6.6和更高的版本,你可以指定每个表的位置使用语句 CREATE TABLE ... DATA DIRECTORY = absolute_path_to_directory, 

你可以运行OPTIMIZE TABLE来压缩或者重新创建一个

file-per-table tablespace.

当你运行一个 OPTIMIZE TABLE,InnoDB 创建一个新的临时名称的.ibd文件，

只使用需要的空间来存储实际的数据。

InnoDB 删除老的.ibd文件用新的替换它。如果前面的.ibd 文件增长显著但是实际的数据

只占用了一部分空间,运行 OPTIMIZE TABLE 可以回收未使用的空间。

4.你可以移动单独的InnoDB 表相比整个数据库

5.你可以复制单个InnoDB表从一个MySQL 实例到

6. 在file-per-table tablespaces  创建的表使用Barracuda 文件格式。

Barracuda file format 启用功能比如也说和动态行格式。

在 system tablespace 创建的表不能使用那些功能。

李亚那些功能对于一个存在的表,启用innodb_file_per_table设置 

运行 ALTER TABLE t ENGINE=INNODB 来替换表

你可以启用更有效率的存储引擎对于BLOB或者TEXT 列使用动态行格式

File-per-table tablespaces 可以提高成功恢复的机会和节省时间当一个腐败发生,

当一个server 不能被重启,或者当备份和binary logs 不可用

你可以备份或者恢复单个表使用MySQL 企业备份产品,

而无需中断其他InnoDB表的使用。

这是有益的 如果你有些表需要较少的备份或者不同的备份计划

File-per-table tablespaces 是方便的对于每个表的状态当复制或者备份表的时候

你可以监控表大小在文件系统层面,不需要访问MySQL

常见的linux 文件系统不允许并发写一个单独的文件当innodb_flush_method 是设置为 O_DIRECT.

因此,有可能的性能改善当使用file-per-table tablespace。

system 表空间存储数据目录和undo logs, 有64TB限制。

通过比较,每个 file-per-table tablespace 有一个64TB 大小限制,

潜在的缺点 对于File-Per-Table 表空间。

1. file-per-table tablespaces, 每个表可能有没有使用的空间, 只能被相同表的记录使用。

这样会浪费空间如果没有妥善管理。

2.fsync 选项必须运行在每个打开的表相比在一个单独的文件,

因此有单独的fsync操作在每个文件,写操作在多个表不能被合并成一个单独的I/O操作。

这个需要InnoDB 执行一个高数量的fsync操作

3.mysqld 必须保持 一个打开的文件句柄对于每个表, 这可能会有性能问题

如果你有多个file-per-table tablespaces 表

4.更多的文件句柄被使用

5. innodb_file_per_table 在MySQL 5.6.6和更高版本默认启用,

你可以考虑关闭如果向后兼容性在MySQL 5.5 or 5.1

关闭innodb_file_per_table防止ALTER TABLE 移动一个InnoDB 表从系统表空间到一个单独的.ibd文件

6.例如,当重新构建InnoDB的 clustered index, 表是被重建使用当前设置的 innodb_file_per_table. 

这个行为不应用当增加或者删除InnoDB secondary indexes. 

7.如果很多表在增长,会有更多的碎片 会阻碍 DROP TABLE 和表扫描性能。

然而, 当碎片化被管理, 它们自己的表空间的文件可以改善性能