binlog是MySQL中Server层面的日志，主要用于主从复制和定点恢复，binlog与redo写入方式不同，redo log是循环写的，而binlog是追加写的。binlog有三种模式，row，statement,mixed模式。目前不少工具的使用前提条件都是日志格式基于row格式的，因此生产上建议使用row格式。

row日志的三种格式:

statement格式：

优点:

1).技术成熟

2).写入日志文件数据较少，当更新或删除涉及多行时，可有效减少存储空间，可以快速根据二级制日志备份和恢复。

3).记录所有数据变更的原始语句，可用于数据库审计。

缺点:

1).执行结果不确定的DML语句，UDF和存储过程，以及不带order by的limit子句，可能会造成主备数据不一致。

2).一些内置函数，如uuid(),user(),sysdate()等时无法正确复制。

3).insert into ...select语句在基于statement的复制时需要的行级锁比基于row的复制多。

4).未使用索引的update语句需要进行表扫描，基于statement的复制时需要的行级锁比基于row的复制多。

5).对于复制语句，需要评估数据一致性风险。

row格式:

优点:

1).可以正确地复制所有数据的变更，是最安全的复制格式。

2).对于Insert into ...select,update或delete语句中where条件未使用索引等场景性能更好。

缺点:

1).生成更多的二进制日志数据，每行数据的变更都会写入二进制日志。

2).利用二进制日志进行备份和恢复是时间更长,另外，二进制日志持有的文件锁时间更长，可能会对数据块并发造成影响。

3).生成大字段的BLOB值会比基于statement的复制消耗更长的时间。

4).无法直接看到从库中执行的语句，需要使用mysqlbinlog工具的--base64-output=decode-rows和--verbose选项查看。

5).对于非事务性表，insert操作多行数据时需要更多的表级锁。

mixed格式:

对于mixed格式的日志，被视作不安全的语句在记录到二进制日志时会被自动转换为row格式，安全的语句会使用statement格式。

其他四种日志相较于前三种重要性略低，因此在一起进行总结。

errorlog(错误日志)：

errorlog记录着mysqld启动和停止，以及服务器在运行过程中发生的错误的相关错误，在服务器运行出现错误时，有助于相关人员进行问题分析，定位问题。

可通过以下参数配置:

log-error：错误日志路径。

slow query log(慢查询日志):

slow query log记录执行时间过长和没有使用索引的查询语句，不会记录执行报错的语句，只会记录执行成功的语句。慢日志可以通过mysqldumpslow，pt-query-digest等工具进行分析。为了便于分析，可对慢日志文件按天进行切割。

可通过以下参数配置:

slow_query_log：是否开启慢日志，on或1为开启。

slow_query_log_file：慢日志路径。

log_query_time：慢查询时间。

通用日志(general log)

general log记录了服务器接收到的每一个查询或者命令，无论这些查询或命令是否正确。默认是关闭的，因为开启general log会对服务器产生不小的系统开销。

中继日志(relay log):

relay log的功能是实现主从同步数据复制。在主从复制中，从库的io线程读取主库的binlog日志，将其转换为relay日志，然后sql线程读取relay log。进行操作回放。