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

你对数据有多重视？

严重的是，每个文件系统都有自己的权衡。 在我走得更远之前，我是XFS和Reiser的忠实粉丝，尽pipe我经常运行Ext3。 所以在这里工作并没有真正的文件系统偏见，只是让你知道…

如果文件系统只不过是一个容器而已，那么就随你提供最好的访问时间。

如果数据有任何显着的价值，您将要避免XFS。 为什么？ 因为如果它不能恢复被logging的文件的一部分， 它将把块清零并使数据不可恢复。 这个问题已经在Linux Kernel 2.6.22中解决了 。

ReiserFS是一个很好的文件系统，只要它从不崩溃 。 日志恢复工作正常，但如果由于某种原因，您丢失了parition信息，或者文件系统的核心块被吹走了，如果磁盘上有多个ReiserFS分区，则可能会遇到困难 – 因为恢复机制基本上扫描整个磁盘，逐个扇区，寻找它“认为”是文件系统的开始 。 如果你有三个ReiserFS分区，但是只有一个被分割，你可以想象这个混乱会引起恢复过程，从另外两个系统中拼出Frankenstein的混乱。

Ext3是“慢”，在“我有32,000个文件，它需要时间来find他们所有运行ls ”方式。 如果你要到处有成千上万张小临时桌，你会有一点点的悲伤。 较新的版本现在包含一个索引选项，可以大大减less目录遍历，但仍然很痛苦。

我从来没有使用过JFS。 我只能评论说，我所阅读过的每一篇评论都是沿着“坚实的，但不是块上最快的孩子”的。 这可能值得调查。

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

XFS：

• 尖叫与巨大的文件，快速恢复时间
• 非常快速的目录search
• 冷冻和解冻文件系统倾倒的原语

ReiserFS文件系统：

• 高度优化的小文件访问
• 将几个小文件打包成相同的块，节省文件系统空间
• 快速恢复，对手XFS恢复时间

EXT3：

• 试验和真实的，基于经过良好testing的Ext2代码
• 大量的工具来处理它
• 可以重新安装为Ext2，以便恢复
• 可以缩小和扩展（其他文件系统只能扩展）
• 最新版本可以扩展“生活”（如果你是大胆的）

所以你看，每个人都有自己的怪癖。 问题是，对你来说最不古怪的是？

也可能值得注意的是，如果没有文件系统，可以运行InnoDB，并且在没有文件系统开销的情况下提高性能。 我不确定我会推荐它，但之前我没有用过它。

InnoDB原始设备

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

这里的答案是严重的废弃，并需要更新，因为这是谷歌的结果。

对于产品环境，XFS。 每次。 XFS是日志式和非阻塞式的。 确保在生产中使用InnoDB的现代（2011/2012）MySQL数据库具有以下variables：

 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级别，不聪明！

来源： – http://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/ – 一些摆动套件，试错。

编辑：更新。 EXT4似乎在2013年中期performance相当不错！ BTRFS仍然不是一个好的select。 而RHEL很可能使XFS成为新的默认文件系统。 再次，不要使用EXT3。

简短的版本是最接近MySQLbuild立在文件系统上的build议是XFS，但是ext3应该也可以，ext4保证是一个不错的改进，但是它仍然不是很稳定，尽pipe它应该在年底。

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

我强烈警告任何Reiser衍生品，而JFS虽然一度很好，但大部分都被XFS和ext4殴打，这些都被广泛部署。

这是不太可能有所作为。 去任何你的分配使用作为其默认，只要它是足够的。

花费你的努力调整其他的东西 – 得到足够的内存 – 得到一个不吸吮的RAID控制器 – 并修复应用程序对数据库的跛脚（ab）使用（注意：这是大多数情况下的主要罪魁祸首已经完成）。

仔细考虑一下你把你的mysql tmpdir放在哪个文件系统上; 这将影响性能，特别是基于光盘的filesort（）的查询（请参阅EXPLAIN获取更多详细信息）。

我认为支持延迟分配的文件系统在这里确实非常方便，因为当有足够的RAM将它们保存在caching中时，可以避免IO完全用于短期文件。 例如，XFS在写入文件之前并不会感到困扰，因为它们在被分配之前被删除并closures。

当然，从性能的angular度来看，tmpfs上的tmpdir是有吸引力的，但是会导致耗尽空间的风险，并且有可能成功的查询（尽pipe使用临时文件）失败。

我没有find任何最近的文章，在各种文件系统上运行MySQL的基准testing。 鉴于你描述的工作量，我怀疑文件级别的碎片将是一个问题。 没有一个正式的基准，我不能说任何你应该采取的权威，但我的直觉说，你上面提到的每个文件系统将大致在同一个球场（即所有的性能数量级相同） 。

数据库真的在运行，因为文件系统只是pipe理存储引擎访问的大范围。

尽pipe如此，对所有这些文件系统进行性能总结还是很有意思的。 （尽pipe我对MySQL没有什么热情，所以我不会去做这件事。标准化Postgres，OTOH可能会很有趣…）

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

XFS（读取速度差）已知在系统资源上很轻，而且大文件很快，但很难处理大量的小文件。

ReiserFS（可怜的写入速度）在系统资源上不是很好，但是对很多小文件performance都非常好。

EXT3介于两者之间，在所有领域都performance出令人满意的性能（之所以认为它是默认的 linux FS）。

我还没有使用EXT4而不是ReiserFS4，但是我已经看了一些基准testing，并且ReiserFS似乎在读取速度方面performance的最好，你说的是最重要的。

看看这个： ReserFS4 X Ext4 X Ext3

我会推荐Ext3的稳定性，安全性和成熟度，但是如果读取速度对你来说最重要，你应该考虑ReiserFS。

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

当然，在您的特定环境中进行试点，testing和基准testing始终是告诉您最适合您的最佳方式。

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