InnoDB 的架构需要使用四种基本类型的信息页面

• 表数据页

• 表索引页

• 表元数据

• MVCC

数据（支持事务隔离和

ACID 合规性

）

• 回滚段
• 撤消空间
• 双写缓冲区（后台写入以防止依赖操作系统缓存）
• 插入缓冲区（管理对非唯一二级索引的更改）

请参阅 ibdata1 的图示

默认情况下，innodb_file_per_table被禁用。这会导致所有四种信息页面类型都登陆一个名为 ibdata1 的文件。许多人试图通过制作多个 ibdata 文件来分散数据。这可能导致数据和索引页面的碎片化。

由于 InnoDB 工作的基础设施，复制是非常危险的。有两个基本的基础设施

• innodb_file_per_table 已禁用
• 已启用 innodb_file_per_table

InnoDB（禁用innodb_file_per_table ）

禁用innodb_file_per_table后，所有这些类型的 InnoDB 信息都存在于 ibdata1 中。ibdata1 之外的任何 InnoDB 表的唯一表现形式是 InnoDB 表的 .frm 文件。一次复制所有 InnoDB 数据需要复制所有 /var/lib/mysql。

复制单个 InnoDB 表是完全不可能的。您必须通过 MySQL 转储来提取表的转储作为数据及其相应索引定义的逻辑表示。然后，您将该转储加载到同一服务器或另一台服务器上的另一个数据库。

InnoDB（启用innodb_file_per_table ）

启用innodb_file_per_table后，表数据及其索引位于 .frm 文件旁边的数据库文件夹中。例如，对于表 db1.mytable，该 InnoDB 表在 ibdata1 之外的表现形式将是：

• /var/lib/mysql/db1/mytable.frm
• /var/lib/mysql/db1/mytable.ibd

系统表空间ibdata1

db1.mytable 的所有元数据仍驻留在 ibdata1中，绝对没有办法解决这个问题。重做日志和 MVCC 数据也仍然存在于 ibdata1 中。

当涉及到表碎片时，ibdata1 会发生以下情况：

• 启用innodb_file_per_tableALTER TABLE db1.mytable ENGINE=InnoDB; ：您可以使用或缩小 db1.mytablesOPTIMIZE TABLE db1.mytable;。这导致 /var/lib/mysql/db1/mytable.ibd 在物理上更小，没有碎片。
• innodb_file_per_table disabled：您不能使用 db1.mytables 来缩小它，ALTER TABLE db1.mytable ENGINE=InnoDB;因为OPTIMIZE TABLE db1.mytable;它与 ibdata1 一起存在。实际运行任一命令，使表连续并更快地读取和写入。不幸的是，这发生在 ibdata1 的末尾。这使得 ibdata1 快速增长。

如果您只想复制 .frm 和 .ibd 文件，那么您将陷入痛苦的世界。仅当且仅当您可以保证 .ibd 文件的表空间 id 与 ibdata1 文件的元数据中的表空间 id 条目完全匹配时，复制 InnoDB 表的 .frm 和 .ibd 文件才有效。

对于 InnoDB，你只需要这个来移动

CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;

制作 InnoDB 表的副本。

如果要将其迁移到另一个数据库服务器，请使用 mysqldump。

关于混合来自所有数据库的所有 InnoDB 表，我实际上可以看到这样做的智慧。在我雇主的数据库/Web 托管公司，我有一个 MySQL 客户端，它在一个数据库中有一个表，其约束映射到同一个 MySQL 实例中另一个数据库中的另一个表。通过一个通用的元数据存储库，它使跨多个数据库的事务支持和 MVCC 可操作性成为可能。