MariaDB系統參數binlog_commit_wait_count引發的單線程單表插入性能低下問題

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系統默認)：

binlog_commit_wait_count = 10
binlog_commit_wait_usec = 6000

10000條數據插入：

# time mysql sbtest < sbtest.sql

real    1m6.715s
user    0m0.280s
sys     0m0.694s

# time mysql sbtest < sbtest.sql

real    1m6.700s
user    0m0.290s
sys     0m0.656s

測試場景二（binlog_commit_wait_usec設置小於系統默認值）：

binlog_commit_wait_count = 0
binlog_commit_wait_usec = 6000

10000條數據插入：

# time mysql sbtest < sbtest.sql

real    0m2.211s
user    0m0.178s
sys     0m0.143s

# time mysql sbtest < sbtest.sql

real    0m2.280s
user    0m0.236s
sys     0m0.188s

測試場景三（binlog_commit_wait_usec = 0）：

binlog_commit_wait_count = 0
binlog_commit_wait_usec = 0

10000條數據插入：

# time mysql sbtest < sbtest.sql

real    0m5.266s
user    0m0.277s
sys     0m0.261s

# time mysql sbtest < sbtest.sql

real    0m5.852s
user    0m0.354s
sys     0m0.312s

測試場景四（系統默認）：

binlog_commit_wait_count = 0
binlog_commit_wait_usec = 100000

10000條數據插入：

# time mysql sbtest < sbtest.sql

real    0m2.598s
user    0m0.373s
sys     0m0.238s

# time mysql sbtest < sbtest.sql

real    0m2.542s
user    0m0.297s
sys     0m0.231s

測試場景五（binlog_commit_wait_usec設置小於系統默認值）：

binlog_commit_wait_count = 0
binlog_commit_wait_usec = 200000

10000條數據插入：

# time mysql sbtest < sbtest.sql

real    0m2.398s
user    0m0.195s
sys     0m0.194s

# time mysql sbtest < sbtest.sql

real    0m2.235s
user    0m0.178s
sys     0m0.163s

結論：

根據官方文檔介紹，這兩個參數應該隻影響主從複製的服務器架構，但實際使用對獨立運行的服務器也有很大的影響，使用binlog_commit_wait_count時單表單線程10000條數據插入耗時1分6秒，不是用該參數時單表單線程10000條數據插入耗時不足3秒。同時關閉binlog_commit_wait_usec時單表單線程10000條數據插入耗時5秒多。binlog_commit_wait_usec取6000/默認值/2倍默認值差異不大，因此建議使用默認參數便可。