为什么 innodb_flush_method = O_DSYNC 通过 SAN 支持的存储提供这样的性能提升？

Question

我见过一些人建议，应O_DSYNC与SAN中使用。

MySQL 文档对 O_DSYNC 的一般情况是这样说的：

在某些版本的 GNU/Linux 和 Unix 中，使用 Unix fsync() 调用（InnoDB 默认使用）和其他类似方法将文件刷新到磁盘的速度非常慢。如果您对数据库写入性能不满意，您可以尝试将 innodb_flush_method 参数设置为 O_DSYNC。O_DSYNC 刷新方法在大多数系统上的执行速度似乎较慢，但您的可能不是其中之一。

并专门针对与SAN使用：

在某些 InnoDB 数据和日志文件位于 SAN 的系统上，对于主要包含 SELECT 语句的读取繁重的工作负载，默认值或 O_DSYNC 可能会更快。始终使用反映您的生产环境的相同类型的硬件和工作负载测试此参数。

尽管他们建议人们应该测试，但措辞是如此空洞（即“某些系统，“可能是”），如果他们甚至不费心进行测试并坚持使用默认值（fdatasync），那么人们可以原谅。但在我的（不科学的）测试我发现 O_DSYNC 提供了巨大的性能优势 - 至少对于一些麻烦的 SELECT 查询。

我想知道是否有人可以更详细地解释为什么这个选项可以在使用 SAN 时提供这样的好处。本好书当然讨论了这个选项，而不是在一个SAN的环境。

我正在使用：

• MySQL 5.1 与 RHEL 6 (x86_64) 上的 InnoDB 插件
• 虚拟化环境（vSphere）；具有 FC 互连的 SAN 由我们的 IaaS 提供商提供
• 带有屏障=0 挂载选项的 Ext4 文件系统
• I/O 调度器是最后期限

Answer 1

• O_DSYNC比O_DIRECT因为它在没有验证的情况下执行写入更快。
• O_DIRECT 偏执但更多数据一致

我之前写过这个：澄清 MySQL innodb_flush_method 变量