sync_binlog:是MySQL 的二进制日志(binary log)同步到磁盘的频率。数据库
sync_binlog=0,当事务提交以后,MySQL不作fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘,而让Filesystem自行决定何时来作同步,或者cache满了以后才同步到磁盘。这个是性能最好的。缓存
sync_binlog=1,当每进行1次事务提交以后,MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。不推荐使用,性能很差。服务器
sync_binlog=n,当每进行n次事务提交以后,MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。并发
innodb_flush_log_at_trx_commit:是 InnoDB 引擎特有的,ib_logfile的刷新方式( ib_logfile:记录的是redo log和undo log的信息)性能
innodb_flush_log_at_trx_commit=0,表示每隔1秒把log buffer刷到文件系统中(os buffer)去,而且调用文件系统的“flush”操做将缓存刷新到磁盘上去。也就是说一秒以前的日志都保存在日志缓冲区,也就是内存上,若是机器宕掉,可能丢失1秒的事务数据。spa
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刷到文件系统中去,但并不会当即刷写到磁盘。若是只是MySQL数据库挂掉了,因为文件系统没有问题,那么对应的事务数据并无丢失。只有在数据库所在的主机操做系统损坏或者忽然掉电的状况下,数据库的事务数据可能丢失1秒之类的事务数据。这样的好处,减小了事务数据丢失的几率,而对底层硬件的IO要求也没有那么高(log buffer写到文件系统中,通常只是从log buffer的内存转移的文件系统的内存缓存中,对底层IO没有压力)。日志