文件系统的选择非常依赖于操作系统。在许多系统中，如Windows就只有一到两个选择，而且只有一个(NTFS) 真的是能用的。比较而言，GNU/Linux则支持多种文件系统。
许多人想知道哪个文件系统在GNU/Linux上能提供最好的MySQL性能，或者更具体一些，哪个对InnoDB和MyISAM而言是最好的选择。实际的基准测试表明，大多数文件系统在很多方面都非常接近，但测试文件系统的性能确实是. 件烦心事。 文件系统的性能是与工作负载相关的，没有哪个文件系统是“银弹”。大部分情况下，给定的文件系统不会明显地表现得与其他文件系统不一样。除非遇到了文件系统的限制，例如，它怎么支持并发、怎么在多文件下工作、怎么对文件切片，等等。
要考虑的更重要的问题是崩溃恢复时间，以及是否会遇到特定的限制，如目录下有许多文件会导致运行缓慢(这是ext2和旧版本ext3下一个臭名昭著的问题，但当前版本的ext3和ex4中用dir index 选项解决了问题)。文件系统的选择对确保数据安全是非常重要的，所以我们强烈建议不要在生产系统做实验。
如果可能，最好使用日志文件系统，例如ext3、ext4、XFS、ZFS或者JFS。如果不这么做，崩溃后文件系统的检查可能耗费相当长的时间。如果系统不是很重要，非日志文件系统性能可能比支持事务的好。例如，ext2 可能比ext3工作得好，或者可以使用tunefs关闭ext3的日志记录功能。挂载时间对某些文件系统也是一个因素。 例如，ReiserFS, 在一个大的分区上可能用很长时间来挂载和执行日志恢复。
如果使用ext3或者其继承者ext4,有三个选项来控制数据怎么记日志，这可以放在/etc/fstab 中作为挂载选项:
data=writeback
这个选项意味着只有元数据写入日志。元数据写入和数据写人并不同步。这是最快的配置，对InnoDB来说通常是安全的，因为InnoDB有自己的事务日志。唯一的例外是，崩溃时恰好导致frm文件损坏了。这里给出一个使用这个配置可能导致问题的例子。当程序决定扩展一个文件使其更大,元数据(文件大小)会在数据实际写到(更大的)文件之前记录并写下操作情况。结果就是文件的尾部最新扩展的区域会包含垃圾数据。
data=ordered
这个选项也只会记录元数据，但提供了--些致性保证，在写元数据之前会先写数据，使它们保持一致。这个选项只是略微比writeback选项慢，但是崩溃时更安全。在此配置中，如果我们再次假设程序想要扩展一个文件，该文件的元数据将不能反映文件的新大小，直到驻留在新扩展区域中的数据被写到文件中了。
data=journal
此选项提供了原子日志的行为，在数据写入到最终位置之前将记录到日志中。这个选项通常是不必要的，它的开销远远高于其他两个选项。然而，在某些情况下反而可以提高性能，因为日志可以让文件系统延迟把数据写入最终位置的操作。
不管哪种文件系统，都有一些特定的选 项最好禁用，因为它们没有提供任何好处， 反而增加了很多开销。最有名的是记录访问时间的选项，甚至读文件或目录时也要进行一次写操作。在letefstab中添加noatime, nodiratime 挂载选项可以禁用此选项，这样做有时可以提高5%一10%的性能,具体取决于工作负载和文件系统(虽然在其他场景下差别可能不是太大)。下面是lelfstab中的一个例子，对ext3选项做设置的行:
/dev/sda2 /usr/ib/mysqI ext3 noatime ndiratie,datawriteback 01
还可以调整文件系统的预读的行为，因为这可能也是多余的。例如，InnoDB 有自己的预读策略，所以文件系统的预读就是重复多余的。禁用或限制预读对Solaris的UFS尤其有利。使用0_DIRECT选项会自动禁用预读。
一些文件系统可能不支持某些需要的功能。例如，若让InnoDB使用0 _DIRECT 刷新方式，文件系统能支持Direct I/O是非常重要的。此外，一.些文件系统处理大量底层驱动器比其他的文件系统更好，举例来说XFS在这方面通常比ext3好。最后，如果打算使用LVM快照来初始化备库或进行备份，应该确认选择的文件系统和LVM版本能很好地协同工作。
