MySQL（InnoDB）最好的Linux文件系统是什么？

我试图在MySQL InnoDB上寻找各种文件系统性能的基准，但是找不到任何基准。

我的数据库工作量是典型的基于Web的OLTP，大约90％的读取，10％的写入。随机IO。

在诸如ext3，ext4，xfs，jfs，Reiserfs，Reiser4等流行的文件系统中，您认为哪一种最适合MySQL？

您对数据有多重视？

认真地说，每个文件系统都有其自身的权衡。在继续进行之前，尽管我经常运行Ext3，但我还是XFS和Reiser的忠实拥护者。因此，这里没有真正的文件系统偏差，只是让您知道...

如果文件系统只不过是您的容器，那么请选择能为您提供最佳访问时间的工具。

如果数据具有重要意义，则应避免使用XFS。为什么？因为如果无法恢复已记录日志的文件的一部分，它将使块归零，并使数据不可恢复。此问题已在Linux Kernel 2.6.22中修复。

ReiserFS是一个很棒的文件系统，只要它永远不会崩溃就行。日志恢复工作正常，但是如果由于某种原因您丢失了分区信息，或者文件系统的核心块被炸毁，则如果磁盘上有多个ReiserFS分区，您可能会感到困惑-因为恢复机制基本上会扫描整个磁盘，逐个扇区，寻找它“认为”的内容是文件系统的开始。如果您有三个带有ReiserFS的分区，但只有一个被炸毁，那么您可以想象这会造成混乱，因为恢复过程将其他两个系统的Frankenstein混乱缝合在一起...

Ext3速度很慢，“我有32,000个文件，要花些时间才能找到全部运行的文件ls”。如果到处都有成千上万的小型临时表，您会感到一丝悲痛。现在，较新的版本包括一个索引选项，该选项可以显着减少目录遍历，但仍然很痛苦。

我从未使用过JFS。我只能评论说，我读过的每条评论都带有“坚如磐石，但不是最快的孩子”的意思。可能值得调查。

足够的缺点，让我们看一下优点：

XFS：

• 尖叫着巨大的文件，快速的恢复时间
• 非常快速的目录搜索
• 冻结和解冻文件系统以进行转储的原语

ReiserFS：

• 高度优化的小文件访问
• 将几个小文件打包到同一块中，以节省文件系统空间
• 快速恢复，可与XFS恢复时间匹敌

Ext3：

• 久经考验，基于经过充分测试的Ext2代码
• 有很多工具可以使用
• 可以在紧急情况下重新安装为Ext2
• 可以缩小和扩展（其他文件系统只能扩展）
• 最新版本可以“实时”扩展（如果您胆敢的话）

如此看来，每个人都有自己的怪癖。问题是，哪一个对您来说最古怪？

可能还值得注意的是，您可以在没有文件系统的情况下运行InnoDB，并在没有文件系统开销的情况下提高性能。我不确定是否会推荐它，但是我之前使用它时都没有问题。

InnoDB原始设备

另外，如果您以90％的读取和10％的写入运行，除非您需要InnoDB的事务处理能力，否则您可能会考虑移植到MyISAM以获得更好的读取性能。

这里的答案已被严重弃用，并且需要更新，因为这会出现在Google搜索结果中。

对于生产环境，请使用XFS。每次。XFS已记录且无阻塞。确保在生产环境中使用InnoDB的现代（2011/2012）MySQL数据库具有以下变量：

innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1 # an ACID requirement
sync_binlog = 1 # more ACID
innodb_flush_method = O_DIRECT

请勿使用EXT3甚至EXT4。有一天BTRFS会到达那里。

EXT3甚至EXT4锁定在inode级别，不是很聪明！

来源：-www.mysqlperformanceblog.com- http ://dev.mysql.com/doc/internals/en/index.html-了解MySQL内幕作者：Sasha Pachev- https://www.facebook.com/note.php？ note_id = 10150210901610933 - http://oss.sgi.com/projects/xfs/training/- 一些摆动套件，反复试验。

编辑：更新。截至2013年中，EXT4的表现似乎不错！BTRFS仍然不是一个好选择。而且RHEL可能会使XFS成为新的默认文件系统。同样，请勿使用EXT3。

简短的版本是最接近我在文件系统上看到的MySQL建议的是XFS，但是ext3也应该可以，ext4可能会是一个不错的改进，但是它仍然不太稳定，尽管应该在年底。

如果您正在运行群集文件系统CXFS，OCFS2和GFS都可以。

我强烈警告任何Reiser派生产品和JFS，尽管曾经不错，但它们都被广泛部署的XFS和ext4击败了。

这不会产生太大的变化。只要分配就足够，请使用您的发行版使用的任何默认设置。

花点力气调整其他东西-获得足够的内存-获得不会吸引的RAID控制器-并修复应用程序的la脚（ab）使用数据库（注意：在大多数情况下，这是主要的罪魁祸首）完成）。

但是，请仔细考虑将mysql tmpdir放在的文件系统。这将影响性能，特别是执行基于磁盘的filesort（）的查询（有关更多详细信息，请参见EXPLAIN）。

我认为支持延迟分配的文件系统在这里确实很方便，因为如果有足够的内存将它们保存在高速缓存中，则可以完全避免对短期文件进行IO。例如，XFS根本不用费心编写在分配文件之前被删除并关闭的文件。

当然，从性能的角度来看，将tmpdir放在tmpfs上很有吸引力，但是会导致耗尽空间和使查询成功的风险（尽管使用了磁盘临时文件）会失败。

我找不到有关在各种文件系统上运行的MySQL基准测试“综述”的最新文章。考虑到您描述的工作量，我怀疑文件级碎片将成为很大的问题。没有正式的基准，我不能说什么您应该具有权威性，但是我的直觉说，您上面提到的每个文件系统都将在大致相同的范围内执行（即，所有相同的性能数量级） 。

数据库实际上正在运行，因为文件系统只是在很大程度上管理存储引擎正在访问的内容。

尽管如此，对所有这些文件系统进行性能汇总还是很有趣的。（不过，我对MySQL的热情不高，因此我不打算承担它。对OTOH的Postgres进行基准测试可能会很有趣...）

恕我直言，Linux值得注意的FS是：

XFS（读取速度较差）已知会占用系统资源，并且处理大型文件时速度较快，但处理许多小型文件时效果较差。

ReiserFS（较差的写入速度）在系统资源上不是很友好，但是在处理许多小文件时表现很好。

EXT3介于两者之间，在所有字段上的性能都可以接受（这是它被视为默认 linux FS 的原因）。

我本人还没有使用EXT4而不是ReiserFS4，但是我已经查看了一些基准测试，在读取速度方面，ReiserFS似乎表现出最好的性能，这对您来说是最重要的。

看看这个：ReserFS4 X Ext4 X Ext3

我建议Ext3具有稳定性，安全性和成熟度，但是如果读取速度对您来说最重要，则应考虑使用ReiserFS。

请记住，在选择FS之前，还应该考虑CPU使用率，稳定性和安全性等。

当然，在您的特定环境上进行试验，测试和基准测试始终是判断哪种方法最适合您的最佳方法。

PS：我会发布更多基准测试，但我不能发布多个链接。