binlog_commit_wait_count和binlog_commit_wait_usec两个参数是MariaDB 10.0开始引入的新参数，根据官方文档介绍：
binlog_commit_wait_count
- Description: For use in parallel replication. The binary log can delay the commit step of a transaction until the given number of transactions are all ready to commit together (group commit). The delay will however not be longer than the value set by binlog_commit_wait_usec. The default value of 0 means that no delay is introduced. Setting this value can reduce I/O on the binary log and give an increased opportunity for parallel apply on the slave, but too high a value will decrease the commit throughput. By monitoring the status variable binlog_group_commit_trigger_count (>=MariaDB 10.1.5) it is possible to see how often this is occurring.
- Starting with MariaDB 10.0.18 and MariaDB 10.1.4: If the server detects that one of the committing transactions T1 holds an InnoDB/XtraDB row lock that another transaction T2 is waiting for, then the commit will complete immediately without further delay. This helps avoid losing throughput when many transactions need conflicting locks. This often makes it safe to use this option without losing throughput on a slave with parallel replication, provided the value of slave_parallel_threads is sufficiently high.
- Commandline: --binlog-commit-wait-count=#]
- Scope: Global
- Dynamic: Yes
- Data Type: numeric
- Default Value: 0
- Range: 0 - 18446744073709551615
- Introduced: MariaDB 10.0.5
binlog_commit_wait_usec
- Description: For use in parallel replication. The binary log can delay the commit step of a transaction by this many microseconds. By monitoring the status variable binlog_group_commit_trigger_timeout (>=MariaDB 10.1.5) it is possible to see how often group commits are made due to binlog_commit_wait_usec. As soon as the number of pending commits reaches binlog_commit_wait_count, the wait will be terminated, though. Thus, this setting only takes effect if binlog_commit_wait_count is non-zero.
- Commandline: --binlog-commit-wait-usec#
- Scope: Global
- Dynamic: Yes
- Data Type: numeric
- Default Value: 100000
- Range: 0 - 18446744073709551615
- Introduced: MariaDB 10.0.5
这两个参数用于并行复制，在并行复制中做一定的延迟，进而使用到组提交这一特性，我的理解是为了提升主从复制的性能，而不影响独立运行的服务器，而实际情况是什么，我们进行如下测试：
测试场景一(binlog_commit_wait_count = 10，binlog_commit_wait_usec系统默认)：
1binlog_commit_wait_count = 10 2binlog_commit_wait_usec = 6000
10000条数据插入：
1# time mysql sbtest < sbtest.sql 2 3real 1m6.715s 4user 0m0.280s 5sys 0m0.694s 6 7# time mysql sbtest < sbtest.sql 8 9real 1m6.700s 10user 0m0.290s 11sys 0m0.656s
测试场景二（binlog_commit_wait_usec设置小于系统默认值）：
1binlog_commit_wait_count = 0 2binlog_commit_wait_usec = 6000
10000条数据插入：
1# time mysql sbtest < sbtest.sql 2 3real 0m2.211s 4user 0m0.178s 5sys 0m0.143s 6 7# time mysql sbtest < sbtest.sql 8 9real 0m2.280s 10user 0m0.236s 11sys 0m0.188s
测试场景三（binlog_commit_wait_usec = 0）：
1binlog_commit_wait_count = 0 2binlog_commit_wait_usec = 0
10000条数据插入：
1# time mysql sbtest < sbtest.sql 2 3real 0m5.266s 4user 0m0.277s 5sys 0m0.261s 6 7# time mysql sbtest < sbtest.sql 8 9real 0m5.852s 10user 0m0.354s 11sys 0m0.312s
测试场景四（系统默认）：
1binlog_commit_wait_count = 0 2binlog_commit_wait_usec = 100000
10000条数据插入：
1# time mysql sbtest < sbtest.sql 2 3real 0m2.598s 4user 0m0.373s 5sys 0m0.238s 6 7# time mysql sbtest < sbtest.sql 8 9real 0m2.542s 10user 0m0.297s 11sys 0m0.231s
测试场景五（binlog_commit_wait_usec设置小于系统默认值）：
1binlog_commit_wait_count = 0 2binlog_commit_wait_usec = 200000
10000条数据插入：
1# time mysql sbtest < sbtest.sql 2 3real 0m2.398s 4user 0m0.195s 5sys 0m0.194s 6 7# time mysql sbtest < sbtest.sql 8 9real 0m2.235s 10user 0m0.178s 11sys 0m0.163s
结论：
根据官方文档介绍，这两个参数应该只影响主从复制的服务器架构，但实际使用对独立运行的服务器也有很大的影响，使用binlog_commit_wait_count时单表单线程10000条数据插入耗时1分6秒，不是用该参数时单表单线程10000条数据插入耗时不足3秒。同时关闭binlog_commit_wait_usec时单表单线程10000条数据插入耗时5秒多。binlog_commit_wait_usec取6000/默认值/2倍默认值差别不大，所以建议使用默认参数即可。