官方文档描述如下：

By default, InnoDB uses the fsync()system call to flush both the data and log files. If

innodb_flush_method option is set to O_DSYNC, InnoDB uses O_SYNC to open and flush the

log files, and fsync()to flush the data files. If O_DIRECT is specified (available on some GNU/

Linux versions, FreeBSD, and Solaris), InnoDBuses O_DIRECT(or directio()on Solaris) to

open the data files, and uses fsync()to flush both the data and log files. Note that InnoDB uses

fsync() instead of fdatasync(), and it does not use O_DSYNC by default because there have

been problems with it on many varieties of Unix.

innodb_flush_method

常规3个值

1、fdatasync

2、O_DSYNC

3、O_DIRECT

正常的访问方式

用户态缓存---》内核态缓存---》磁盘

按照MYSQL的描述

1、fdatasync

InnoDB uses the fsync() system call to flush both the data and log files.

Note that InnoDB uses fsync() instead of fdatasync()

虽然MYSQL可以使用fdatasync为参数但是实际上是调用的系统的 fsync()函数，

我们可以看看LINUX下FSYNC()函数的描述

fsync()  transfers  ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the

file descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved  even

after  the  system crashed or was rebooted.  This includes writing through or flushing a disk cache if present.  The call blocks

until the device reports that the transfer has completed.  It also flushes metadata information associated with  the  file  (see

stat(2)).

简单的说这个参数用于同步所有线程修改过的文件，而进程中的PCB中记录了打开文件，他是通过文件描述符进行匹配的

在LINUX内核中/usr/src/linux-headers-3.19.0-25-generic/include/linux/sched.h

有如下的PCB结构体

struct task_struct { }

其中有一个files_struct的结构体，而文件描述符就是这样一个结构体的指针

那么只要MYSQL线程进行了刷新动作，那么他的这些文件的数据一定会同步到磁盘

2、O_DSYNC

InnoDB uses O_SYNC to open and flush the log files, and fsync()to flush the data files

当设置为这个选项的时候，当MYSQL线程打开LOGFILE的时候使用的O_SYNC的方式，而对数据文件还是使用的fsync()

我们知道对一个文件进行读，打开是使用LINUX的

open()函数，而其中也就有这样一个选项

O_SYNC The  file  is  opened for synchronous I/O.  Any write(2)s on the resulting file descriptor will block the calling process

until the data has been physically written to the underlying hardware.

他描述的是如果这样打开一个文件那么在数据从内核态缓存写到了物理磁盘前，任何试图修改文件描述符的进程都会被堵塞。如此保证了日志文件

最大的安全性

3、O_DIRECT

If O_DIRECT is specified (available on some GNU/Linux versions, FreeBSD, and Solaris), InnoDB

uses O_DIRECT(or directio()on Solaris) to open the data files, and uses

fsync()to flush both the data and log files.

使用这个选项MYSQL使用O_DIRECT方式打开数据文件，而fsync()会最终同步所有的数据和日志文件。

我们同样看看open()函数中关于O_DIRECT描述

O_DIRECT (Since Linux 2.4.10)

Try to minimize cache effects of the I/O to and from this file.  In general this will degrade performance, but it is use‐

ful  in special situations, such as when applications do their own caching.  File I/O is done directly to/from user-space

buffers.  The O_DIRECT flag on its own makes an effort to transfer data synchronously, but does not give  the  guarantees

of  the  O_SYNC flag that data and necessary metadata are transferred.  To guarantee synchronous I/O, O_SYNC must be used

in addition to O_DIRECT.

使用这个选项一般来说会降低性能，但是在特定的情况下比如应用程序有自己的缓存机制。I/O直接来自用户态的缓存，O_DIRECT标识对大量的

数据写有利，因为他绕开了内核态缓存，但是他并同步METADATA(这里占时理解为INODE缓存，也就是文件的基本信息比如打开时间修改时间等)

所以要完成同步必须同时调用O_SYNC。

如此我们也了解为什么为什么使用O_DIRECT还会调用FSYNC()我们知道FSYNC()是全同步的，LINUX上的传统的FDATASYNC()是不同步METADATA的

如INODE缓存，进程描述缓存。但是他能够对大量的数据绕开缓存，提高性能，需要最后同步的只是DATAFILE的METADAT。

MYSQL有自己的缓冲，这种可以使用O_DIRECT比较好

水平有限，如有错误请指出

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/7728585/viewspace-1980262/，如需转载，请注明出处，否则将追究法律责任。