参数说明：

不管在官网还是其他网站上均能看到innodb_flush_log_at_trx_commit=【0，1，2】三种值：

innodb_flush_log_at_trx_commit = 0 ：每秒将日志缓冲区写入log file，并同时flush到磁盘。跟事务提交无关。在机器crash并重启后，会丢失一秒的事务日志数据（并不一定是1s，也许会有延迟，跟操作系统调度有关）。

innodb_flush_log_at_trx_commit = 1：每次事务提交将日志缓冲区写入log file，并同时flush到磁盘。（crash不会丢失事务日志）

innodb_flush_log_at_trx_commit = 2：每次事务提交将日志缓冲区写入log file，每秒flush一次到磁盘。（crash有可能丢失数据）

测试验证：

环境说明：

操作系统：windows 7
MySQL：5.6.26

准备：

-- 建立测试表
use test
create table t_innodb (a int) engine=innodb;
create table t_myisam (a int) engine=myisam;
-- 建立插入数据存储过程
delimiter //
create procedure insert_testdata(p1 int)
begin
 set @x:=0;
 repeat
  set @x:[email protected]+1;
  insert into t_myisam values (@x);
  insert into t_innodb values (@x);
  commit;
 until @x>p1 end repeat;
end
//
delimiter ;

(1)innodb_flush_log_at_trx_commit = 0 测试

net stop mysql   --停止Mysql服务
更新my.ini
  innodb_flush_log_at_trx_commit = 0   --更新innodb_flush_log_at_trx_commit = 0
  net start mysql 　　　　　　　　--重新启动Mysql服务  mysql -u root -p   use test   call insert_testdata(1000000);  将mysqld进程杀掉。模拟crash场景。  net start mysql

结果截图：

(2)innodb_flush_log_at_trx_commit = 1 测试

truncate table t_innodb;
truncate table t_myisam;
net stop mysql
更新my.ini
  innodb_flush_log_at_trx_commit = 1
net start mysql
mysql -u root -p
use test
call test_insertdata(1000000);

将mysqld进程杀掉。模拟crash场景。

(3)innodb_flush_log_at_trx_commit = 2 测试

truncate table t_innodb;
truncate table t_myisam;
net stop mysql
更新my.ini
  innodb_flush_log_at_trx_commit = 2
net start mysql
mysql -u root -p
use test
call insert_testdata(1000000);

将mysqld进程杀掉。模拟crash场景。

重启后，数据未丢失。

再次 call insert_testdata(1000000); 将mysqld进程杀掉。模拟crash场景。丢失一条数据。

注意：

大家肯定记得还有控制二进制日志的 sync_binlog 参数，而且还会很容易混淆，下面谈一谈sync_binlog：

sync_binlog = 0  （mysql默认值 ）由文件系统决定将binlog同步到硬盘。

sync_binlog = 1  每提交一次事务，写一次binlog，并使用fdatasync()同步到硬盘。

sync_binlog > 1  每提交一次事务，写一次binlog，达到sync_binlog 设定的值后，调用fdatasync()同步到硬盘。

（1）如果在主从复制架构下：

在 sync_logbin = 1 的情况下， 每次提交事务都会同步到磁盘，保证日志的持久性，也可以保证主从复制的一致性 。

在 sync_logbin = 0，或者>1的值，很有可能机器出现crash，日志并没有同步到磁盘，重启后，二进制日志的position比备库同步过去的position小，造成数据不一致情况。

（2）没有主从架构，单独数据库实例：

在 sync_logbin = 1 的情况下， 每次提交事务都会同步到磁盘，保证日志的持久性，能够保证存储下了所有提交的事务 。能够用来进行恢复。

在 sync_logbin = 0，或者>1的值，很有可能机器出现crash，日志并没有同步到磁盘，重启后，二进制日志很可能丢失已提交事务，所以不能用来进行恢复操作，因为它有丢失事务。

总结：

innodb_flush_log_at_trx_commit 参数对数据完整性有非常大的作用，强烈建议使用 innodb_flush_log_at_trx_commit = 1 ； sync_binlog = 1 ； --虽然会很影响性能，但是对于数据很重要的情况下，必须设置。