日志类型：
- 错误日志(error log)
- 常规日志(general log)
- 二进制日志(bin log)
- 中继日志(relay log)
- 慢日志(slow log)
- InnoDB引擎的redo log
这里查看的是跟binlog有关的变量（这是因为之前在搭建MHA高可用架构是配置文件中设置的二进制的名字就是binlog：log_bin=binlog）
1.binlog_cache_size参数
<1>含义：
为每个session 分配的内存，在事务过程中用来存储二进制日志的缓存。
<2>作用：
提高记录bin-log的效率
<3>属性：
参数：global;
默认值：32768 -- 即32K;
范围：4096 .. 4294967295
<4>大小选择：
a.根据业务：
没有什么大事务，DML(数据库管理语言)也不是很频繁的情况下可以设置小一点，如果事务大而且多，DML操作也频繁，则
可以适当的调大一点。
前者建议是1048576 --1M
后者建议是：2097152 -- 4194304 即 2--4M
b.根据参数：
show global status like 'bin%';
上述语句我们可以得到当前 数据库binlog_cache_size的使用情况
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Binlog_cache_disk_use | ???
| Binlog_cache_use | ?????Binlog_cache_disk_use表示因为我们binlog_cache_size设计的内存不足导致缓存二进制日志用到了临时文件的次数
Binlog_cache_use 表示用binlog_cache_size缓存的次数
当对应的Binlog_cache_disk_use值比较大的时候,我们可以考虑适当的调高binlog_cache_size对应的值
<5>注意点：
a.max_binlog_cache_size 表示的是binlog能够使用的最大cache内存大小
当我们执行多语句事务的时候,所有session的使用的内存超过max_binlog_cache_size的值时
就会报错：“Multi-statement transaction required more than 'max_binlog_cache_size' bytes ofstorage”
b.设置太大的话，会比较消耗内存资源;设置太小又会使用到临时文件即disk
2. binlog_checksum参数
<1>含义：
二进制日志事件校验和
<2>注意点：
mysql5.6.5以后的版本中binlog_checksum默认值是crc32；
而之前的版本binlog_checksum默认值是none
3.binlog_direct_non_transactional_updates参数
这个参数默认值是off。我们开启他，这样不管任何情况对非事务表的操作都将记录binlog。
4.binlog_error_action参数
默认参数是：ABORT_SERVER
Binlog_error_action参数控制当不能写binlog时，mysql-server将会采取什么行动。
设置binlog_error_action=ABORT_SERVER会使mysql-server在写binlog遇到严重错误时退出，比如磁盘满了，文件系统不可写入了等。在ABORT_SERVER选项下，binlog和从库都是安全的，这是官方修改此默认值的原因。
在先前的选项下（binlog_error_action=IGNORE_ERROR），如果一个错误发生，导致无法写入binlog，mysql-server会在错误日志中记录错误并强制关闭binlog功能。这会使mysql-server在不记录binlog的模式下继续运行，导致从库无法继续获取到主库的binlog。
5.binlog_format参数
默认值是ROW
当开启binlog并且binlog格式设置为ROW模式时，每张表的行变动被写到binlog文件中，然后这些变动在从库端应用。这和使用statement格式binlog是不同的。在STATEMENT格式下，binlog会在从库端重新执行。
所有的数据库变动都能被复制并且这是最安全的复制方式。同基于statement的复制相比，基于row的复制需要的行级锁定更少。在先前的默认statement格式下，不确定的状态可能会造成主从不一致的问题。
6.binlog_group_commit_sync_delay参数
全局动态变量，单位微妙，默认0，范围：0～1000000（1秒）。
表示binlog提交后等待延迟多少时间再同步到磁盘，默认0，不延迟。设置延迟可以让多个事务在同一时刻提交，提高binlog组提交的并发数和效率，提高slave的吞吐量。
7.binlog_group_commit_sync_no_delay_count参数
全局动态变量，单位个数，默认0，范围：0～1000000。
表示等待延迟提交的最大事务数，如果上面参数的时间没到，但事务数到了，则直接同步到磁盘。若binlog_group_commit_sync_delay没有开启，则该参数也不会开启。
8.binlog_gtid_simple_recovery参数
默认值是ON
这个参数控制了当mysql启动或重启时，mysql在搜寻GTIDs时是如何迭代使用binlog文件的。
这个选项设置为ON，会提升mysql执行恢复的性能。因为这样mysql-server启动和binlog日志清理更快。该参数为ON时，mysql-server只需打开最老的和最新的这2个binlog文件，gtid_purged参数的值和gtid_executed参数的值可以根据这些文件中的Previous_gtids_log_event 或者 Gtid_log_event计算得出。这确保了当mysql-server重启或清理binlog时，只需打开2个binlog文件。
在MySQL-5.6中，调整这个选项设置也同样会提升性能，但是在一些特殊场景下，计算gtids值可能会出错。而保持这个选项值为false，能确保计算总是正确。
在MySQL-5.7.7中，几乎不需要在速度和安全性之间做权限。设置该选项为TRUE总能得到正确的结果，除了以下2个极端场景：
- 最新的binlog是MySQL-5.7.5(或更老版本)产生的，并且gtid_mode对一些binlog设置为ON，但是对最新的binlog设置为OFF.
- GTID_PURGED的状态是MySQL-5.7.7之前的版本发布的，并且在当时激活清理的binlog在当前仍然没有清理完成。
因此，开启这个选项几乎总是更好一些，所以这个选项默认开启。
如果这个参数设置为off，在mysql恢复期间为了初始化gtid_executed，所有以最新文件开始的binlog都要被检查。并且为了初始化gtid_purged，所有的binlog都要被检查。这可能需要非常长的时间。
9.binlog_max_flush_queue_time参数
默认值是0
单位为微妙，leader线程搜集binlog的超时时间。
10.binlog_order_commits参数
默认值是ON
我们知道当binlog_order_commits关闭时，表示我们能接收binlog commit和innodb commit的顺序不同（这不会带来数据不一致，但可能会影响到热备份），关闭该选项可以带来一定程度的性能提升。
11.binlog_row_image参数
binlog_row_image这个参数是MySQL5.6新增的参数，默认值是FULL，在5.7版本默认值也是FULL。
该参数设置的前提：
binlog格式必须为row格式或者mixed格式，不可以是statement格式。名称解释：
before image：前镜像，即数据库表中修改前的内容。
after image：后镜像，即数据库表中修改后的内容。binlog_row_image三种设置及异同
binlog_row_image参数可以设置三个合法值: FULL、MINIMAL、NOBLOB
三个不同值的作用如下：
- FULL: Log all columns in both the before image and the after image.
binlog日志记录所有前镜像和后镜像。
- MINIMAL: Log only those columns in the before image that are required to identify the row to be changed; log only those columns in the after image where a value was specified by the SQL statement, or generated by auto-increment.
binlog日志的前镜像只记录唯一识别列(唯一索引列、主键列)，后镜像只记录修改列。
- noblob: Log all columns (same as full), except for BLOB and TEXT columns that are not required to identify rows, or that have not changed.
binlog记录所有的列，就像full格式一样。但对于BLOB或TEXT格式的列，如果他不是唯一识别列(唯一索引列、主键列)，或者没有修改，那就不记录。
12.binlog_rows_query_log_events参数
在row模式下...开启该参数，将把sql语句打印到binlog日志里面。默认是off；
虽然将语句放入了binlog，但不会执行这个sql，就相当于注释一样。但对于dba来说，在查看binlog的时候。很有用处。
13.binlog_stmt_cache_size参数
同binlog_cache_size
与binlog_cache_size的差别在于
- binlog_cache_size #事务缓存大小
- binlog_stmt_cache_size #非事务语句缓存大小
14.binlog_transaction_dependency_history_size参数
此参数在版本8.0.1中引入，是可以动态调整的global级参数，默认值为25000，可以设置为0-1000000之间的任意整数。8.0基于WriteSet进行并行复制时，WriteSet是一个hash数组，binlog_transaction_dependency_history_size值就是这个hash数组的最大值。
15.binlog_transaction_dependency_tracking参数
要注意，从库上可能会出现与在主库上出现的不一样的数据视图（比如查询数据时默认的显示顺序和在主库上查询结果不同）。这是因为事务可能被按照与主库不同的顺序去回放。
为了控制这个新的行为（从库上数据回放顺序），可以设置参数binlog_transaction_dependency_tracking（此参数在8.0.1版本引入），该参数的选项有：
COMMIT_ORDER：默认值，它使用 MySQL 5.7 中可用的默认机制。
WRITESET：它能实现更好的并行化，并且在主库的二进制日志中存储writeset数据。
WRITE_SESSION：它确保事务在从库中按顺序执行，并且消除了从库中看到主库从未出现过的数据库状态的问题。它降低了并行化程度，但是仍然提供了比默认设置更好的吞吐量。
16.innodb_api_enable_binlog参数
默认值是off
控制是否可以使用innodb memcached插件和mysql binary log
17.innodb_locks_unsafe_for_binlog参数
静态参数，默认为0，表示启动gap lock；如果设置为1，表示禁用gap lock。这时mysql就只有record lock了，不过值得注意的是，即使了设置了1，关于外键和唯一键重复检查方面用到的gap lock依旧有效。这时可以简单地理解成事务的隔离级别退化成可重复读，然后两者应该还是有所区别的。建议是不要随便设置。
- Record lock单条索引记录上加锁，record lock锁住的永远是索引，而非记录本身，即使该表上没有任何索引，那么innodb会在后台创建一个隐藏的聚集主键索引，那么锁住的就是这个隐藏的聚集 主键索引。所以说当一条sql没有走任何索引时，那么将会在每一条聚集索引后面加X锁，这个类似于表锁，但原理上和表锁应该是完全不同的。
- Gap lock在索引记录之间的间隙中加锁，或者是在某一条索引记录之前或者之后加锁，并不包括该索引记录本身。gap lock的机制主要是解决可重复读模式下的幻读问题，关于幻读的演示和gap锁如何解决了幻读。关于这一块，先给出几个定义。
快照读：
简单的select操作，没有lock in share mode或for update，快照读不会加任何的锁，而且由于mysql的一致性非锁定读的机制存在，任何快照读也不会被阻塞。但是如果事务的隔离级别是SERIALIZABLE的话，那么快照读也会被加上共享的next-key锁，本文不对SERIALIZABLE隔离级别做叙述。
当前读：
官方文档的术语叫locking read，也就是insert，update，delete，select..in share mode和select..for update,当前读会在所有扫描到的索引记录上加锁，不管它后面的where条件到底有没有命中对应的行记录。当前读可能会引起死锁。
意向锁：
innodb的意向锁主要用户多粒度的锁并存的情况。比如事务A要在一个表上加S锁，如果表中的一行已被事务B加了X锁，那么该锁的申请也应被阻 塞。如果表中的数据很多，逐行检查锁标志的开销将很大，系统的性能将会受到影响。为了解决这个问题，可以在表级上引入新的锁类型来表示其所属行的加锁情 况，这就引出了“意向锁”的概念。举个例子，如果表中记录1亿，事务A把其中有几条记录上了行锁了，这时事务B需要给这个表加表级锁，如果没有意向锁的 话，那就要去表中查找这一亿条记录是否上锁了。如果存在意向锁，那么假如事务Ａ在更新一条记录之前，先加意向锁，再加Ｘ锁，事务B先检查该表上是否存在意 向锁，存在的意向锁是否与自己准备加的锁冲突，如果有冲突，则等待直到事务Ａ释放，而无须逐条记录去检测。事务Ｂ更新表时，其实无须知道到底哪一行被锁 了，它只要知道反正有一行被锁了就行了。
说白了意向锁的主要作用是处理行锁和表锁之间的矛盾，能够显示“某个事务正在某一行上持有了锁，或者准备去持有锁”不可重复读：
指的是在同一个事务中，连续几次快照读，读取的记录应该是一样的
不可重复读的演示较为简单，本文不做讨论。
幻读：
指的是在一个事务A中执行了一个当前读操作，而另外一个事务B在事务A的影响区间内insert了一条记录，这时事务A再执行一个当前读操作时，出 现了幻行。这和不可重复读的主要区别就在与事务A中一个是快照读，一个当前读；并且事务B中一个是任何的dml操作，一个只是insert。比如在A中 select * from test where id<10 lock in share mode结果集为（1,2,3），这时在B中对test表插入了一条记录4，这时在A中重新查询结果集就是(1,2,3,4），和事务A在第一次查询出来 的结果集不一致，这里的4就是幻行。
演示条件：由于可重读的隔离级别 下，默认采用Next-Key Locks，就是Record lock和gap lock的结合，即除了锁住记录本身，还要再锁住索引之间的间隙，所以这个gap lock机制默认打开，并不会产生幻行，那么我们要演示幻行的话，要么将隔离级别改为read-commited，要么在REPEATABLE-READ 模式下禁用掉gap lock，这里我们采用的是第二种方式。
18.log_statements_unsafe_for_binlog参数
全局动态变量，默认ON。
表示是否记录error code '1592′ 信息到错误日志里。error code '1592′：Unsafe statement written to the binary log using statement format
19. max_binlog_cache_size参数
默认值是18446744073709547520，这个值很大，够我们使用的了。此参数和binlog_cache_size相对应，是所代表的是binlog能够使用的最大cache内存大小。
当我们执行多语句事务的时候，max_binlog_cache_size如果不够大的话，系统可能会报出“Multi- statementtransactionrequiredmorethan'max_binlog_cache_size'bytesofstorage” 的错误。
20.max_binlog_size参数
1073741824=1G binlog的最大值，一般设置为512M或1G,一般不能超过1G;
该大小并不能非常严格控制Binlog大小，尤其是当到达Binlog比较靠近尾部而又遇到一个较大事务的时候，系统为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进入当前日志，直到该事务结束。
这一点和Oracle的Redo日志有点不一样，因为Oracle的Redo日志所记录的是数据文件的物理位置的变化，而且里面同时记录了Redo和Undo相关的信息，所以同一个事务是否在一个日志中对Oracle来说并不关键。
而MySQL在Binlog中所记录的是数据库逻辑变化信息，MySQL称之为Event，实际上就是带来数据库变化的DML之类的Query语句。
21.max_binlog_stmt_cache_size参数
同max_binlog_size
与max_binlog_size的不同在于：
- max_binlog_size #针对事务缓存大小而言的最大值
- max_binlog_stmt_cache_size #针对非事务语句缓存大小而言的最大值
22.sync_binlog参数
这个参数是对于MySQL系统来说是至关重要的，他不仅影响到Binlog对MySQL所带来的性能损耗，而且还影响到MySQL中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下：
- sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。
- sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。
在MySQL中系统默认的设置是sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。
而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为1的时候，即使系统Crash，也最多丢失binlog_cache中未完成的一个事务，对实际数据没有任何实质性影响。从以往经验和相关测试来看，
对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。
这里查看的是跟log有关的变量
我们比较关注的其中的一个参数：expire_logs_days。
这个参数主要用来控制binlog日志文件保留时间，超过保留时间的binlog日志会被自动删除。
比如我们指定expire_logs_days=7，表示表示最近7天的binlog日志，7天以前的binlog日志会被自动删除。
这个参数的默认值是0，表示永不过期。
我们比较关注的另外一个参数：slow_query_log。
这个参数用来控制是否开启慢查询日志的。
这个参数有两个取值（on表示启用慢查询日志；off表示禁用慢查询日志）
这个参数的默认值是off，表示禁用慢查询日志。
这里举个例字：
我们可以利用登陆数据库，输入命令"set global slow_query_log=1"来开启慢查询日志。
开启慢查询日志之后，会在/var/lib/mysql目录下生成对应的慢查询日志。
这里查看的是跟long有关的变量
我们这里比较关注的参数是long_query_time。
这个参数的含义是：SQL语句运行时间阀值，表示执行时间大于等于参数值的语句才会在慢查询日志中记录下来。
这个参数的默认值是10秒。
这里举个例字：
我们可以登陆数据库，输入命令"select sleep(10)"来使得查询时间为10秒，输入命令"select sleep(5)"来使得查询时间为5秒。
我们会发现，慢日志中，只记录了select sleep(10)，而并没有记录select sleep(5)。
