MySQL的innodb_flush_log_at_trx_commit和sync_binlog 怎样区分MySQL的innodb_flush_log_at_trx_commit和sync_binlo

innodb_flush_log_at_trx_commit和sync_binlog  两个参数是控制MySQL磁盘写入策略以及数据安全性的关键参数。

show variables like "innodb_flush_log_at_trx_commit";

innodb_flush_log_at_trx_commit:

0: 由mysql的main_thread每秒将存储引擎log buffer中的redo日志写入到log file，并调用文件系统的sync操作，将日志刷新到磁盘。

1：每次事务提交时，将存储引擎log buffer中的redo日志写入到log file，并调用文件系统的sync操作，将日志刷新到磁盘。

2：每次事务提交时，将存储引擎log buffer中的redo日志写入到log file，并由存储引擎的main_thread 每秒将日志刷新到磁盘。

show variables like "sync_binlog";

sync_binlog：

0 ：存储引擎不进行binlog的刷新到磁盘，而由操作系统的文件系统控制缓存刷新。

1：每提交一次事务，存储引擎调用文件系统的sync操作进行一次缓存的刷新，这种方式最安全，但性能较低。

n：当提交的日志组=n时，存储引擎调用文件系统的sync操作进行一次缓存的刷新。

sync_binlog=0或sync_binlog大于1，事务被提交，而尚未同步到磁盘。因此，在电源故障或操作系统崩溃时有可能服务器已承诺尚未同步一些事务到二进制日志。因此它是不可能执行例行程序恢复这些事务，他们将会丢失二进制日志。

innodb_flush_log_at_trx_commit和sync_binlog 都为 1 时是最安全的，在mysqld 服务崩溃或者服务器主机crash的情况下，binary log 只有可能丢失最多一个语句或者一个事务。但是鱼与熊掌不可兼得，双1，1 会导致频繁的io操作，因此该模式也是最慢的一种方式。

实际使用时，要考虑业务方对性能和安全性的需求，综合考量设置，两个参数。上图中是我们线上机器的参数。