通常 RDBMS（我是 MySQL 用户）性能的瓶颈是磁盘访问。与传统的主轴驱动器相比，SSD 提供了出色的性能。
问题：是否可以通过连接多个减少空间的驱动器来提高性能，因为这样有更多的磁头可用于读取数据？
就像用 4 500GB 7.2k RPM 驱动器替换 2TB 7.2k RPM 驱动器一样？
AskOverflow.Dev
通常 RDBMS（我是 MySQL 用户）性能的瓶颈是磁盘访问。与传统的主轴驱动器相比，SSD 提供了出色的性能。
问题：是否可以通过连接多个减少空间的驱动器来提高性能，因为这样有更多的磁头可用于读取数据？
就像用 4 500GB 7.2k RPM 驱动器替换 2TB 7.2k RPM 驱动器一样？
这在很大程度上取决于存储引擎。
对于 MyISAM，我认为这将是一个好主意，因为您可以根据需要使数据连续。这将有利于涉及批量操作和大范围扫描的查询。用于压缩和修复 MyISAM 以改进表格格式的工具集也可以使访问更好一些。恕我直言，并发 INSERT 可以在这样的磁盘环境中蓬勃发展。
InnoDB 是一个完全不同的故事。
如果您禁用了innodb_file_per_table，则数据可以分散在整个 ibdata1 中，从而分散在多个磁盘中。您可以对 InnoDB 表运行 OPTIMIZE TABLE 并使数据和索引页连续，但这可能会导致两个问题：
不要忘记驻留在 ibdata1 中的四种类型的数据：
不断写入 MVCC 数据以保护数据完整性。还有与 ib_logfile0 和 ib_logfile1（重做日志）的持续交互。从 InnoDB 缓冲池到 . 总体而言，可以肯定地说，在 ibdata1 内存在足够的碎片之前，跨多个磁盘的数据分布和 I/O 性能可以显示出边际到适度的性能改进。
现在，如果启用了 innodb_file_per_table，事情可能会有点混乱。原因如下：
清理 ibdata1 并将所有 InnoDB 表与 ibdata1 分开后，您将拥有一个更小的 ibdata1。但是，对 InnoDB 表的每次访问都需要始终通过表元数据通过 ibdata1 导航其使用。您实际上无法在语义上将表元数据 (ibdata1) 与表 (.ibd) 分开。无论 ibdata1 位于何处，磁盘 I/O 都必须始终通过 ibdata1。
整体效果：表碎片仅限于.ibd文件，可以通过OPTIMIZE TABLE减少和重组，但并没有真正实现额外的I/O性能提升。
将所有 .ibd 文件放入除 ibdata1 之外的不同磁盘集并使用符号链接怎么样？根据 Percona 的说法，这会造成更多混乱。
结论
当谈到在单个驱动器上使用多个驱动器时，我非常喜欢 MyISAM 而不是 InnoDB。
是的，由于我们称之为 RAID 的出色技术，多个驱动器将提供更好的吞吐量。对于数据库，您需要 RAID 10（条带镜像）。
使用 4(N) 个驱动器，您的写入速度将增加一倍 (N/2)，顺序读取吞吐量将增加四倍 (N)。不过，搜索时间将大致保持不变，并且您将失去一半的镜像空间。