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 等修改数据的语句，那么还是会记录所有行的变更。
