很多翻译文章都把innodb_flush_log_at_trx_commit的翻译得很勉强，导致阅读中文解析也不能完全理解，今天翻了下官方文档，大致意思如下：


当设置1时（默认值）：

每次事务提交（commit），都会将log buffer的内容写到（write out）log file，并做刷写(flush to disk)操作（保证数据持久化)


当设置0时：

大约每秒(考虑程序调度，不保证每秒)都将log buffer的内容写到（write out）log file，并做刷写(flush to disk)操作（保证数据持久化)。但执行事务提交（commit）时，不会做任何写和刷写操作（可以理解为忽略commit对刷新的行为）。


当设置2时：

每次事务提交（commit），都会将log buffer的内容写到（write out）log file。大概每秒(考虑程序调度，不保证每秒)进行刷写(flush to disk)操作（保证数据持久化)。


总结：

1、原文最后说明了设置为1，也不一定保证完整，因为os和硬盘也会骗过mysql(伪刷写)。

2、当设置为0和2，由于“考虑程序调度，不保证每秒”的关键字，所以如果真是每秒都有操作，那么不会丢失数据，但如果运气差点，碰巧刷写延迟了，就会出现文中的可能丢失1-2秒数据(丢失多少秒数据就看延迟了多久了)。

3、当设为0时，当mysql进程奔溃，就有机会丢失数据。

4、当设为2时，当服务器和os原因奔溃重启，才有机会丢失数据。相对0来说靠谱点，所以如果考虑io性能而不设1，我建议设为2。


官方原文内容：

http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit


Controls the balance between strict ACID compliance for commit operations, and higher performance that is possible when commit-related I/O operations are rearranged and done in batches. You can achieve better performance by changing the default value, but then you can lose up to a second of transactions in a crash.


The default value of 1 is required for full ACID compliance. With this value, the contents of the InnoDB log buffer are written out to the log file at each transaction commit and the log file is flushed to disk.


With a value of 0, the contents of the InnoDB log buffer are written to the log file approximately once per second and the log file is flushed to disk. No writes from the log buffer to the log file are performed at transaction commit. Once-per-second flushing is not 100% guaranteed to happen every second, due to process scheduling issues. Because the flush to disk operation only occurs approximately once per second, you can lose up to a second of transactions with any mysqld process crash.


With a value of 2, the contents of the InnoDB log buffer are written to the log file after each transaction commit and the log file is flushed to disk approximately once per second. Once-per-second flushing is not 100% guaranteed to happen every second, due to process scheduling issues. Because the flush to disk operation only occurs approximately once per second, you can lose up to a second of transactions in an operating system crash or a power outage.


As of MySQL 5.6.6, InnoDB log flushing frequency is controlled by innodb_flush_log_at_timeout, which allows you to set log flushing frequency to N seconds (where N is 1 ... 2700, with a default value of 1). However, any mysqld process crash can erase up to N seconds of transactions.


DDL changes and other internal InnoDB activities flush the InnoDB log independent of the innodb_flush_log_at_trx_commit setting.


InnoDB's crash recovery works regardless of the innodb_flush_log_at_trx_commit setting. Transactions are either applied entirely or erased entirely.


For durability and consistency in a replication setup that uses InnoDB with transactions:


If binary logging is enabled, set sync_binlog=1.


Always set innodb_flush_log_at_trx_commit=1.


Caution

Many operating systems and some disk hardware fool the flush-to-disk operation. They may tell mysqld that the flush has taken place, even though it has not. Then the durability of transactions is not guaranteed even with the setting 1, and in the worst case a power outage can even corrupt InnoDB data. Using a battery-backed disk cache in the SCSI disk controller or in the disk itself speeds up file flushes, and makes the operation safer. You can also try using the Unix command hdparm to disable the caching of disk writes in hardware caches, or use some other command specific to the hardware vendor.