14.7.4 InnoDB File-Per-Table Tablespaces

14.7.4 InnoDB File-Per-Table Tablespaces

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

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

任何磁盘存储分配给MySQL 不会被其他目的需要.

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

每个InnoDB 表和他的索引是存储在一个单独的.ibd文件。

每个这样的.ibd文件代表一个单独的表空间。

这个功能是通过innodb_file_per_table 配置选项,默认启用在5.6.6和更高版本

文件表空间的优势:

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

 Truncating or dropping 表存储在共享的系统表空间创超的空闲空间在系统表空间数据文件内(ibdata files)

这个只能用于InnoDB data

同样, 一个表复制 ALTER TABLE 操作在表上 位于一个共享的tablespace 可以增加空间使用的总量

这样的操作需要额外的空间等同于表和索引的大小。

这个额外的空间需要用于表复制ALTER 操作是不释放回操作系统 

3. TRUNCATE 表操作是快速的在一个表存储在file-per-table tablepaces. 

你可以存储特定的表在单独的存储设备,对于I/O 优化, 空间管理,或者备份目的。

在以前的版本, 你只能移动整个数据库目录到其他设备

和创建软连接在MySQL 数据目录

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

你可以运行OPTIMIZE TABLE 来压缩或者重新创建一个 file-per-table  表空间。

当你运行一个 OPTIMIZE TABLE,  InnoDB 创建一个新的.ibd file 使用一个临时的名字,

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

当优化器是完成后,InnoDB 删除老的.ibd文件和替换为新的,

如果先前的.ibd文件增长显著 但是实际数据只占用它的大小的一部分,运行OPTIMIZE TABLE可以回收不使用的空间

你可以移动单个InnoDB表相比整个数据库

你可以复制单个InnoDB 表从MySQL 实例到另外的地方

表创建在 file-per-table tablespaces 使用 Barracuda file format.

Barracuda file format 有压缩和动态行格式的功能。

表创建在system 表空间不能使用那些功能。

利用那些功能对于一个存在的表,启用 innodb_file_per_table setting 运行ALTER TABLE t ENGINE=INNODB t

来放置表在一个 file-per-table tablespace.

你可以让更有效的表的存储 使用 BLOB or TEXT columns 使用动态行格式

File-per-table tablespaces 可以改善恢复的机会,当一个corruption 发生时节省时间,

当一个拂去其不能启动时, 或者当备份和binary logs 是不可用时

你可以备份或者恢复单个表使用MySQL Enterprise Backup product, 不需要中断其他InnoDB 表的使用。

这是有益的 如果你的表需要不频繁的备份或者 不同的备份计划

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

你不能监控表大小在系统层面,不访问MYSQL 数据库的话

常用的Linux 文件系统不允许 并发写到一个单独的文件 当 innodb_flush_method 是设置为O_DIRECT

mysql> show variables like '%innodb_flush_method%';
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| innodb_flush_method |       |
+---------------------+-------+
1 row in set (0.00 sec)

因此, 有可能性能改善党使用 file-per-table 表空间

 File-Per-Table Tablespaces 存在的缺点:

1. file-per-table tablespaces 每个表有一个未使用的空间, 只能被相同表的行使用。

这个会浪费空间 

2.fsync 操作必须允许在每个打开的表相比在一个单独的文件。因为 这里有一个单独的fsync 操作在每个文件,

写操作在多个表不能合成一个单独的I/O操作。 这个可能需要InnoDB 执行更多数量得到fsync操作

3.mysqld 必须每个表一个文件句柄, 这可能会影响性能 如果你有大量的表

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

5.innodb_file_per_table  是默认启用的在 MySQL 5.6.6和更高版本。

你可以考虑禁用它如果和mysql 5.5或者5.1的兼容性是一个问题。

6.例如, 当重新组织 clustered index 对于一个InnoDB 表,

表时重新创建使用当前设置对于innodb_file_per_table. 

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

当一个 secondary index 被创建没有rebuild 表。

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