binlog_cache_size
每个线程的binlog cache大小，如果超过了会将binlog暂存到磁盘上，影响性能。
binlog_checksum
binlog校验码，默认是采用CRC32，会为每一个binlog event写一个校验码；可指定为none关闭，关闭后只通过binlog event的长度来校验一致性。
binlog_direct_non_transactional_updates
在statement格式的binlog模式下，对于一个事务包含非事务表和事务表，MySQL会试图将非事务语句暂存在一个事务cache里，而不是非事务语句执行完之后就马上写入非事务语句的binlog；
最终是等到发起commit时，才按照事务里的语句顺序写入binlog，通过这种方式尽可能地保证在一个事务里非事务语句和事务语句的先后顺序，防止在从库复制发生主从不一致的情况。
而binlog_direct_non_transactional_updates默认OFF，就代表以上的处理方法；如果binlog_direct_non_transactional_updates设为on，则表示一个事务里的非事务语句执行完后，马上写入binlog。
binlog_error_action
5.7.7以后，默认为abort_server，表示当binlog出现无法写入，无法flush，或无法sync时，MySQL主动关闭实例；到重启时，所有处于prepared阶段且提交binlog成功的事务会被commit，而处于prepared但未写入binlog的事务，会回滚。
还可以取值为ignore_error，表示当binlog出现无法写入，无法flush，或无法sync时，关闭binlog模式，但MySQL实例继续对外提供服务；要恢复binlog功能，要重新开启log_bin参数。
该参数在较早的版本里对应binlogging_impossible_mode。
binlog_format
binlog格式，有row,statement,mixed，大部分环境都是使用row格式，配合RC事务隔离级别。
需要注意的是在statment格式下，对replicate-do-db等过滤功能的影响。
binlog_group_commit_sync_delay
设置binlog组提交的延迟毫秒数，即在binlog sync之前，等待多少毫秒。
当sync_binlog=0 or sync_binlog=1，这个延迟设置是应用在每一个组提交上；
当sync_binlog=N,N>1，这个延迟设置是累积了N个group commit之后才开始计算延迟。
此参数可以配合slave_parallel_type=logical_clock来提高并行复制的优化效果。
此参数也可以减少操作系统的fsync()负载；但是此参数降低了实例的吞吐量，因为延迟了提交，客户端也就得到延迟的提交反馈。
binlog_group_commit_sync_no_delay_count
设置累积了多少个group commit以后，就忽略binlog_group_commit_sync_delay的延迟设置，开始执行binlog sync。
binlog_gtid_simple_recovery
是否开启gtid简单恢复，同5.7.5引入的参数simplified_binlog_gtid_recovery，5.7.6后改名为binlog_gtid_simple_recovery。
GTID为什么要恢复？GTID不是记录在mysql.gtid_executed里吗？
MySQL5.7开始使用mysql.gtid_executed表来记录gtid信息，可以不需要强制开启log-slave-updates，但是gtid_executed表记录gtid的方式也有讲究。
在关闭binlog或者关闭log_slave_updates时（针对slave），MySQL会在每个事务执行时记录该事务的GTID；
当binlog开启时，当前binlog里gtid只有到rotate下一个binlog文件时，才会把这个binlog文件相关的gtid信息记录到gtid_executed表里。
所以当实例崩溃时，最新binlog里的gtid信息是还没有记录到gtid_executed表里的，重启实例的时候就需要进行gtid恢复。
当binlog_gtid_simple_recovery=false，
崩溃后恢复gtid_executed时，从最新的binlog往前迭代，直到读到有Previous_gtids_log_event的binlog，读取该binlog的Previous_gtids_log_event和Gtid_log_events里的gtid，并且把这些gtid在内部存储起来，称为gtids_in_binlog；而gtid_executed就是用gtids_in_binlog和mysql.gtid_executed记录的gtid做并集得到；
崩溃后恢复gtid_purged时，从最老的binlog往后迭代，直到读到Previous_gtids_log_event不为空或者至少有一个Gtid_log_event的binlog，从这个binlog读取Previous_gtids_log_event里的gtid，然后拿恢复gtid_executed时的gtids_in_binlog减去这里得到的gtid，也就是得到还没purged的gtid，内部存储在gtids_in_binlog_not_purged；最后gtid_purged=gtid_executed-gtids_in_binlog_not_purged。
这里得到gtid_purged为什么要这么绕？我猜应该是最老的binlog里的Previous_gtids_log_event有可能不全吧，否则直接拿来做gtid_purged也行得通。
当binlog_gtid_simple_recovery=true,
崩溃后恢复gtid信息时，只读取当前最老和最新的binlog；所以当这两个binlog里恰好没有gtid信息，也就是说在这两个binlog在用的时候关闭了gtid模式，那么就得不到正确的gtid信息。
binlog_max_flush_queue_time
5.7.9开始已废弃，在旧版本，这个参数控制在group commit以前继续从flush队列里读取事务的时间。
binlog_order_commits
控制binlog的顺序是否与事务提交顺序一致。
binlog_row_image
在row格式的binlog模式下，该参数控制binlog记录的详细程度。可取值full,minimal,noblob。
full，记录一行数据所有列的信息，即使有些列没有被操作；
mimimal，只记录被操作和可以唯一标记该行的列；
noblob，和full相似，但是不记录blob和text类型的列。
binlog_rows_query_log_events
对于row格式的binlog模式，是否记录binlog对应的SQL；开启后可用mysqlbinlog -vvv来查看SQL。
binlog_stmt_cache_size
在事务里有非事务语句时，会在binlog statement cache里暂存相关SQL，该参数决定cache大小，每个线程独立分配。
binlog_transaction_dependency_tracking
控制采用哪种并行复制策略，可取值
COMMIT_ORDER，根据同时进入prepare和commit来判断可以并行复制；
WRITESET，每个事务涉及操作的每一行，计算出每一行的hash值，组成集合writeset，如果两个事务没有操作相同的行，就是可并行的；
WRITESET_SESSION，在WRITE基础上多一个限制，同一个线程的执行顺序要有保证。
binlog_transaction_dependency_history_size
在代码实现上，MySQL采用一个vector的变量存储已经提交的事务的HASH值，所有已经提交的事务的所修改的主键和非空的UniqueKey的值经过HASH后与该vector中的值对比，由此来判断当前提交的事务是否与已经提交的事务更新了同一行，并以此确定依赖关系。
该向量的大小由参数binlog_transaction_dependency_history_size控制，取值范围为1-1000000 ，初始默认值为25000。
innodb_locks_unsafe_for_binlog
默认为0，表示启用gap锁，innodb使用next-key锁来进行索引扫描；设为1即禁用gap锁。
log_statements_unsafe_for_binlog
控制当出现error 1592，是否将错误记录到error log。
max_binlog_cache_size
没看懂跟binlog_cache_size的区别。
max_binlog_size
binlog文件大小，超过该值会将binlog写入新的文件，但是事务的binlog是作为一个整体写入binlog文件的，所以如果存在一个大事务，那么binlog文件大小即使超过max_binlog_size，也会保存完整的事务binlog。
如果没有设置max_relay_log_size，这个值也对relay log文件起效。
max_binlog_stmt_cache_size
没看懂跟binlog_stmt_cache_size的区别。