MySQL的binlog日志作用是用来记录MySQL内部增删改查等对MySQL数据库有更新的内容的记录（对数据库的改动），对数据库的查询select或show等不会被binlog日志记录，主要用于数据库的主从复制以及增量恢复。

MySQL的binlog日志必须打开logbin功能才能生成binlog日志。

binlog是MySQL中一个重要的部分，主要作用有两个：

• Replication：在master端开启binary log后，log会记录所有数据库的改动，然后slave端获取这个log文件内容就可以在slave端进行同样的操作。
• 备份：在某个时间点a做了一次备份，然后利用binlog记录从这个时间点a后的所有数据库的改动，然后下一次还原的时候，利用时间点a的备份文件和这个binlog文件，就可以将数据还原。

一、开启MySQL的binlog

查看是否启用了日志：

select @@version; # 5.6.29

show VARIABLES like 'log_bin'; # ON
show VARIABLES like 'binlog_format'; # STATEMENT

在Linux 平台中，更新MySQL 配置文件：vim /etc/my.cnf。

开启mysql binlog，并且设置binlog format为ROW模式：

[mysqld]
log-bin=mysql-bin
binlog_format=ROW
server_id=112233

重启MySQL 服务：

service mysql restart

再次验证binlog format 格式，已经更新为ROW模式。

进入到配置文件/etc/my.cnf中查看mysql数据文件存放路径：datadir 配置项。

发现有很多bin文件，说明binlog日志开启成功，能实时记录保存DML操作。

查看Log文件： SHOW BINARY LOGS;

二、MySQL binlog的三种工作模式

（1）Row level

日志中会记录每一行数据被修改的情况，然后在slave端对相同的数据进行修改。

优点：能清楚的记录每一行数据修改的细节。

缺点：数据量太大。

比如有这样一条 update 语句：

UPDATE product SET product_name= 'b' WHERE product_name= 'a'

执行之后，日志中记录的不是这条 update 语句所对应的事件 (MySQL 以事件的形式来记录 bin-log 日志) ，而是这条语句所更新的每一条记录的变化情况，这样就记录成很多条记录被更新的很多个事件。

（2）Statement level（默认）

每一条被修改数据的sql都会记录到master的bin-log中，slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql再次执行。

优点：解决了 Row level下的缺点，不需要记录每一行的数据变化，减少bin-log日志量，节约磁盘IO，提高性能。

缺点：容易出现主从复制不一致。

（3）Mixed（混合模式）

结合了Row level和Statement level的优点。

在 Mixed 模式下，MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种。新版本中的 statment 还是和以前一样，仅仅记录执行的语句。而新版本的 MySQL 中对 row 模式也被做了优化，并不是所有的修改都会以 row 模式来记录，比如遇到表结构变更的时候就会以 statement 模式来记录，如果 SQL 语句确实就是 update 或者 delete 等修改数据的语句，那么还是会记录所有行的变更。