mysql 组提交及涉及的参数

为什么要有组提交？
为了保证安全性，需要设置双1，但是在设置双1后，每次的提交都会去刷盘，每次刷盘的话，io会是瓶颈，于是有了组提交。
5.6中采用的Group Commit技术将事务的提交阶段分成了 Flush, Sync, Commit 三个阶段，每个阶段维护一个队列，并且由该队列中第一个线程负责执行该步骤，这样实际上就达到了一次可以将一批事务的Binlog fsync到磁盘的目的，这样的一批同时提交的事务称为同一个Group的事务。
索引并行复制就是基于组提交复制了。
为了标记事务所属的组，MySQL 5.7 版本在产生 Binlog 日志时会有两个特殊的值记录在Binlog Event中， last_committed 和 sequence_number , 其中 last_committed 指的是该事务提交时，上一个事务提交的编号，sequence_number 是事务提交的序列号，在一个Binlog文件内单调递增。如果两个事务的 last_committed 值一致，这两个事务就是在一个组内提交的。

组提交有redo，和binlog的组提交
为了避免每个提交flush，innodb使用了组提交来提升吞吐，就是将同一时间点的多个用户的事务分为一组，向日志文件做一次写入。
官网上介绍不多:
找一些连接：https://www.sohu.com/a/242875539_610509
在这个连接的描述中，看的貌似是先flush redo 在写的binlog

关于组提交中的数据一致性问题
默认情况下，二进制日志不是在每次的写都同步到磁盘，因此就有丢失的危险，sync_binlog这个参数是在每n个提交组后同步到磁盘，最安全的是1，就是1个组提交一次，但是任然会有丢失数据的危险，在使用的时候，系统顺序写入多个预备好的事务到二进制日志，同步二进制日志，提交事务，如果在同步二进制日志及提交的时候除了问题，事务回滚了，但是数据已经在二进制日志中了，这种情况下可以通过设置innodb_support_xa=1来解决，这个参数确保了二进制日志和innodb数据文件的同步，这个选项的作用是，在crash后重启的时候，mysql会检查二进制日志收集xid的值和计算最后的有效位置，mysql会告诉innodb完成写入二进制的预备好的事务，然后截取二进制日志到最后的有效点，这样就确保了二进制日志与数据文件的一致，从库仍然与主库保持一致，因为从库不会接收回滚的语句，这种只是在master没有failover的情况下，master还是之前的master,但是如果做了failover，那么之前的从库上如果没有接受到二进制日志，在failover后，新主库上就比新从库少数据了。

组提交涉及的参数:
binlog_group_commit_sync_delay:该参数控制着在刷新二进制日志到磁盘之前commit等待多久，单位毫秒，默认是0，不延迟，在很多事务提交的情况下，有助于减少整体的替吉奥时间，sync_binlog=0或sync_binlog=1，这个参数的设置影响每个组替吉奥，当sync_binlog设置是n，那么延时会应用到每n个组上，设置这个参数可以增加并发提交事务，增大从库的并发复制能力，但是从库需要设置slave_parallel_type=logical_clock，当binlog_transaction_dependency_tracking=commit_order的时候，效果更好，这个参数就是能减少刷盘的次数，但是增加了事务的时延，高并发的时候也会出现竞争，从而导致吞吐的下降，因此这个参数设置需谨慎。
binlog_group_commit_sync_no_delay_count：达到这个参数指定的事务数后，抛弃上一个参数的设置。