MySQL InnoDB 数据文件直接位于磁盘片上（固定大小）？

Question

看来ibdata1就像一个磁盘切片。在 Solaris (UNIX) UFS 文件系统（ZFS 之前的常见文件系统）中，人们会将其磁盘 c0t0d0 分成多个片，例如将 10GB 驱动器切成三个部分，4GB、1GB 和 5GB。这些将是固定大小的文件系统。例如，操作系统的 4GB。1GB 用于交换，5GB 用于软件和数据。

swap 可以存储在文件系统上的文件中，但为了性能，它通常存储在磁盘的自己部分。

ibdata1 可以链接到它自己的切片以提高性能吗？当然，在决定理想的固定大小之前必须仔细考虑，他们还必须知道如何检查使用水平。

符号链接可以放置在.../mysql/data/ibdata1到/dev/rdsk/c0t0d0s3。然后 MySQL 会将其视为文件，但可能会执行得更好，因为它不必通过文件系统层，它会直接写入磁盘的指定部分。

• 有没有人试过这个？
• 有没有人认为这是一个坏主意？（请记住，这个想法仅适用于 InnoDB-only 数据库服务器。不是多用途服务器。）
• 它会起作用吗（innodb 是否需要检查文件长度？如果没有，它应该起作用。）
• 可以检查使用情况吗？

Answer 1

首先，驻留在 ibdata1 中的条目类型是什么？四 (4) 个条目类型：

• 表元数据
• 表数据页
• 索引数据页
• MVCC数据

每当 InnoDB 表遇到 DDL、DML 或在事务中使用时，所有这四种类型的条目都会被读取或写入。同时，如果innodb_file_per_table被禁用，所有这些条目类型都存在于 ibdata1 中。如果启用，则只有表元数据和 MVCC 数据将驻留在 ibdata1 中，而表数据页和索引数据页将作为 .ibd 文件驻留在数据库子文件夹中。

考虑到这一点，如果将 ibdata1 放在另一个卷中并进行符号链接会发生什么？

首先，无论存储引擎如何，MySQL 如何表示表？作为 .frm 文件。.frm 文件在哪里？在数据目录中。那有什么问题？

下面是一个例子：

使用 /var/lib/mysql 的默认数据目录，让我们使用名为 mydb.mytable 的 InnoDB 表。

禁用 innodb_file_per_table 后，所有内容都将位于 ibdata1（您建议对其进行符号链接并发送到另一个数据卷）。对于表 mydb.mytable，您将拥有以下内容：

• /var/lib/mysql/mydb/mytable.frm
• 关于表的所有其他内容都在 ibdata1 中

现在想象一下：您访问该表，MySQL 将首先访问 /var/lib/mysql/mydb/mytable.frm，然后针对 mydb.mytable 访问 ibdata1 中的数据和索引页。每次访问 mydb.mytable 时都会发生这种情况。这种来回级联会以某种方式使事情变慢，并且通过将 ibdata1 移动到其他一些数据卷，您可能无法获得预期的性能。事实上，级联效应现在是 InnoDB 表数量乘以二 (2) 的一个因素。

想象一下启用了 innodb_file_per_table。现在你会有一个稍微不同的设置：

• /var/lib/mysql/mydb/mytable.frm
• /var/lib/mysql/mydb/mytable.ibd
• MVCC 数据和表元数据将驻留在 ibdata1

这种级联会更糟，因为表访问的级联现在发生在三个文件而不是两个文件中。

这是一些人想到的另一种情况：与其将 ibdata1 移动到不同的卷，不如启用 innodb_file_per_table 并将 .ibd 文件移动到一个或多个不同的数据卷？级联效应现在是 InnoDB 表数量乘以三 (3) 的一个因素。Percona 已经表达了不这样做的很好的理由，你会发现这很有帮助。