我们先简单了解一下大致的刷盘时机，然后配合两阶段提交和组提交来看
redo log的刷盘时机
- MySQL 正常关闭时；
- 当 redo log buffer 中记录的写入量大于 redo log buffer内存空间的一半时，会触发落盘；
PS：为什么这里要到一半就要刷了，因为redo log buffer是一个环状的内存结构，会被反复利用 - InnoDB 的后台线程每隔 1 秒，将 redo log buffer 持久化到磁盘。
- 由系统参数innodb_flush_log_at_trx_commit 参数控制。
参数为1的时候会主动持久化到磁盘，但是0和2不会，那么这两个什么时候持久化到磁盘呢？
我们可以通过系统变量来查看这个参数
mysql> show variables like '%innodb_flush_log_at_trx_commit%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1 |
+--------------------------------+-------+
1 row in set (0.00 sec)
好了,redo log介绍完了，接着我们来介绍bin log的刷盘时机。
bin log的刷盘时机
每个线程有自己 binlog cache，最终会都写到同一个 binlog 文件。
binlog的刷盘过程：
（1） write，指的就是指把日志写入到 binlog 文件，但是并没有把数据持久化到磁盘，因为数据还缓存在文件系统的 page cache 里，write 的写入速度还是比较快的，因为不涉及磁盘 I/O。
（2）fsync，才是将数据持久化到磁盘的操作，这里就会涉及磁盘 I/O，所以频繁的 fsync 会导致磁盘的 I/O 升高。
那么什么时候刷盘呢？
通过sync_binlog 参数来控制数据库的 binlog 刷到磁盘上的频率：
我们通过命令行来查看参数：
mysql> show variables like '%sync_binlog%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog | 1 |
+---------------+-------+
1 row in set (0.00 sec)
两次提交、组提交、双参数配合实现了两个日志的同步
有了前面两个刷盘时机，为什么还要有两次提交，因为我们需要保证redo log和bin log的一致性。
两阶段提交的过程是如何的？
具体的取决于我们的参数，参数一共有四个分别如下所示：
mysql> show variables like '%sync_binlog%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog | 1 |
+---------------+-------+
1 row in set (0.00 sec)
mysql> show variables like '%innodb_flush_log_at_trx_commit%';
+--------------------------------+-------+
| Variable_name | Value |
+--------------------------------+-------+
| innodb_flush_log_at_trx_commit | 1 |
+--------------------------------+-------+
1 row in set (0.00 sec)
mysql> show variables like '%binlog_group%';
+-----------------------------------------+---------+
| Variable_name | Value |
+-----------------------------------------+---------+
| binlog_group_commit_sync_delay | 1000000 |
| binlog_group_commit_sync_no_delay_count | 10 |
+-----------------------------------------+---------+
2 rows in set (0.00 sec)
其中，我们看到了两个新参数，他们是组提交参数：
不同的参数效果都是不一样的。
1、我们先来看最经典的双1配置
此刻事务提交时需要花费1.00 sec，因为binlog_group_commit_sync_delay设置的是1s，binlog_group_commit_sync_no_delay_count和binlog_group_commit_sync_delay满足其中一条即可
2、在双1的基础上，如果我们把innodb_flush_log_at_trx_commit改了呢？
每次redo log都没有刷盘，我们默认就成功了。
3、在双1的基础上，如果我们把sync_binlog改了呢？
此时事务提交只需要0.00sec，可以判定提交的瞬间未刷盘，但是提交成功了。因为sync_binlog=N，在后续的1~N-1的事务，commit都是很快，第N个事务commit所消耗的时间是1s左右。也就是在第N次时候，进行了刷盘。
这时候有人疑惑了，那么我的组提交参数有啥用？
我们来看结论：
开启两个并行的窗口，这两个窗口同时commit提交，并设置binlog_group_commit_sync_no_delay_count =2，我们发现刷盘了。 也就是说组提交在事务并行的时候才有效果。为什么要在并行事务的时候才有效果？
所以sync_binlog和组提交之间是相互配合而不是冲突矛盾的关系，在事务并发时组提交生效，而在没有并发时候，syc_binlog就发挥了巨大作用。
好了，关于日志刷盘的内容就到这了。
