似乎 ibdata1 就像一个磁盘片。在 Solaris (UNIX) UFS 文件系统（ZFS 之前的常见文件系统）中，人们会将其磁盘 c0t0d0 分成多个片，例如一个 10GB 的驱动器将被分成三个部分，4GB、1GB 和 5GB。这些将是固定大小的文件系统。例如，操作系统的 4GB。1GB 用于交换，5GB 用于软件和数据。
swap 可以存储在文件系统上的文件中，但为了性能，它通常存储在磁盘的自己的部分。
ibdata1 可以链接到自己的切片以提高性能吗？当然，在决定理想的固定大小之前，必须仔细考虑，他们还必须知道如何检查使用水平。
符号链接可以放置 from.../mysql/data/ibdata1到/dev/rdsk/c0t0d0s3。MySQL 会将其视为一个文件，但性能可能会更好，因为它不必经过文件系统层，它会直接写入磁盘的指定部分。
- 有没有人试过这个？
- 有人认为这是一个坏主意吗？（请记住，这个想法适用于仅 InnoDB 仅数据库服务器。不是多用途服务器。）
- 它可以工作吗（innodb 需要检查文件长度吗？如果没有，它应该可以工作。）
- 可以检查使用情况吗？
首先，驻留在 ibdata1 中的条目类型是什么？四 (4) 个条目类型：
每当 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 表，您将拥有以下内容：
现在想象一下：您访问表，MySQL 将首先访问 /var/lib/mysql/mydb/mytable.frm，然后访问 ibdata1 中的数据和索引页以获取 mydb.mytable。这将在每次访问 mydb.mytable 时不断发生。这种级联来回会以某种方式使事情变慢，并且您可能无法通过将 ibdata1 移动到其他数据量来获得预期的性能。事实上，级联效应现在将是 InnoDB 表的数量乘以二 (2) 的一个因素。
想象一下启用了 innodb_file_per_table 。现在你会有一个稍微不同的设置：
这种级联会更糟一些，因为表访问的级联现在将发生在三个文件而不是两个文件之间。
这是一些人想到的另一种情况：与其将 ibdata1 移动到不同的卷，不如启用 innodb_file_per_table 并将 .ibd 文件移动到一个或多个不同的数据卷？级联效应现在将是 InnoDB 表数量乘以三 (3) 的一个因素。Percona 已经表达了不这样做的很好的理由，你会发现这很有帮助。