InnoDB提供了innodb_flush_log_at_trx_commit参数,它有三种可能取值:
查看mysql变量:show VARIABLES LIKE 'innodb_flush_log_at_trx_commit'
binlog的写入策略,write 和fsync的时机,是由参数sync_binlog控制的:
sync_binlog=0
的时候,表示每次提交事务都只write
,不fsync
;sync_binlog=1
的时候,表示每次提交事务都会执行fsync
;sync_binlog=N(N>1)
的时候,表示每次提交事务都write
,但累积N
个事务后才fsync
。因此,在出现IO瓶颈的场景里,将sync_binlog
设置成一个比较大的值,可以提升性能。在实际的业务场景中,考虑到丢失日志量的可控性,一般不建议将这个参数设成0
,比较常见的是将其设置为100~1000中的某个数值。
但是,将sync_binlog
设置为N
,对应的风险是:如果主机发生异常重启,会丢失最近N
个事务的binlog
日志。
通常情况下,生产都是" 双1 "的配置
,也就是sync_binlog
和 innodb_flush_log_at_trx_commit
的配置都是1
,也就是说,一个事务完整提交前,需要等待两次刷盘,一次是redo log
,一次是binlog
。
如果你的MySQL现在出现了性能瓶颈,而且瓶颈在IO上,可以通过哪些方法来提升性能呢?
针对这个问题,可以考虑以下三种方法:
binlog_group_commit_sync_delay
和 binlog_group_commit_sync_no_delay_count
参数,减少binlog的写盘次数。这个方法是基于“额外的故意等待”来实现的,因此可能会增加语句的响应时间,但没有丢失数据的风险。sync_binlog
设置为大于1的值(比较常见是100~1000)。这样做的风险是,主机掉电时会丢binlog日志。innodb_flush_log_at_trx_commit
设置为2。这样做的风险是,主机掉电的时候会丢数据。我不建议你把innodb_flush_log_at_trx_commit
设置成0。因为把这个参数设置成0,表示redo log
只保存在内存中,这样的话MySQL本身异常重启也会丢数据,风险太大。而redo log
写到文件系统的page cache
的速度也是很快的,所以将这个参数设置成2
跟设置成0
其实性能差不多,但这样做MySQL异常重启时就不会丢数据了,相比之下风险会更小。