http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_method
基于上面的一篇文章,如果我们选择O_DIRECT选项,它会描述
O_DIRECT:InnoDB使用O_DIRECT(或Solaris上的directio())打开数据文件,并使用fsync()刷新数据和日志文件.
由于O_DIRECT意味着没有\最小化数据将被缓存在内核页面缓存中,但是fsync()用于将数据从页面缓存刷新到设备,所以我的问题是为什么MYSQL仍然使用fsync()来刷新数据时选项是O_DIRECT？
实际上，解释已添加到您在O_DIRECT选项描述之后的段落中链接的文档中（突出显示的是我的）：
O_DIRECT_NO_FSYNC：InnoDB 在刷新 I/O 期间使用 O_DIRECT，但之后跳过 fsync() 系统调用。此设置适用于某些类型的文件系统，但不适用于其他类型的文件系统。例如，它不适用于 XFS。如果您不确定您使用的文件系统是否需要 fsync()，例如保留所有文件元数据，请改用 O_DIRECT。这个选项是在 MySQL 5.6.7 (Bug #11754304, Bug #45892) 中引入的。
MySQL 错误#45892包含附加信息：
Domas 的一些测试表明，某些文件系统 (XFS) 在没有 fsync 的情况下不会同步元数据。如果元数据会发生变化，那么您仍然需要使用 fsync（或 O_SYNC 来打开文件）。
例如，如果在启用 O_DIRECT 时文件增长，它仍将写入文件的新部分，但是由于元数据不反映文件的新大小，因此在发生崩溃时尾部可能会丢失。
解决方案：
当重要的元数据发生变化时继续使用 fsync，或者在 O_DIRECT 之外使用 O_SYNC。
总结一下：不对某些文件系统使用 fsync() 会导致 MySQL 失败。但是，从 v5.6.7 开始，MySQL 提供了通过添加O_DIRECT_NO_FSYNC选项来配置 MySQL（以及 innodb）在这方面针对您自己的操作系统功能量身定制的选项。