sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。
这个是性能最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。
sync_binlog=1，当每进行1次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。
sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。
innodb_flush_log_at_trx_commit=0，每隔一秒把log buffer刷到文件系统中(os buffer)，并调用文件系统的“flush”操作将缓存刷新到磁盘上去。
也就是说一秒之前的日志都保存在日志缓冲区，如果机器宕掉，可能丢失1秒的事务数据。
innodb_flush_log_at_trx_commit=1，每次事务提交的时候，都把log buffer刷到文件系统中(os buffer)，并调用文件系统的“flush”操作将缓存刷新到磁盘上去。
数据库对IO的要求就非常高，如果底层的硬件提供的IOPS比较差，那么MySQL数据库的并发很快就会由于硬件IO的问题而无法提升。
innodb_flush_log_at_trx_commit=2，每次事务提交的时候会把log buffer刷到文件系统中(os buffer)，但并不会立即刷写到磁盘。
如果只是MySQL数据库挂掉了，由于文件系统没有问题，那么对应的事务数据并没有丢失。如果数据库所在的主机操作系统损坏或者突然掉电的情况下，数据库的事务数据可能丢失1秒之类的事务数据。
好处，减少了事务数据丢失的概率，而对底层硬件的IO要求也没有那么高(log buffer写到文件系统中，一般只是从log buffer的内存转移的文件系统的内存缓存中，对底层IO没有压力)。
原文：https://www.cnblogs.com/wjh123/p/11386410.html