A：记录所有对MySQL数据库的修改事件（包括增删改查事件和对表结构修改的事件），而且只记录已经成功执行的事件（失败的不会记录）
这么说可能有点抽象，熟悉SQLServer的同志看个图就秒懂：
STATEMENT 基于段的格式，记录执行数据修改时候所执行的SQL语句
ROW 基于行的格式，记录增删改查操作所修改行的信息（每修改一行就会有一条信息）
MIXED 基于行和端的混合格式，根据SQL语句由系统决定是基于段还是基于行的日志格式记录
查看方式：show variables like 'binlog_format';
binlog_format=statement：基于段的记录格式（老版本的默认值）
优点：记录量较小，节约磁盘和网络IO（单条操作Row更节约）
缺点：必须记录上下文信息来保证语句在从服务器上执行结果与主服务器相同
但是如果使用了uuid()、user()等结果非确定的函数，可能会造成MySQL主从不一致
日志查看：mysqlbinlog /var/lib/mysql/binlog.0000xx | more（不用指定参数）
binlog_format=row：基于行的记录格式（5.7以后的默认值）
优点：可以避免MySQL复制中出现的主从不一致的问题（主从更安全）
PS：没有备份的时候可以通过分析row格式的二进制日志来反向恢复
缺点：记录日志量较大（顺序写入）
现在增加了新参数来优化：binlog_row_image=[full|minimal|noblob]
日志查看：mysqlbinlog -vv /var/lib/mysql/binlog.0000xx | more
binlog_format=mixed：基于行和端的混合格式（推荐）
PS：数据量大小由所执行的SQL决定（非确定性函数越多，行数越多）
PS：DDL操作（create、drop、alter）的时候都是基于段方式来记录log
如果一条一条记录，表有上亿数据，我就修改某列的状态值，那不得疯？
对binlog_row_image=[FULL|MINIMAL|NOBLOB]的补充说明：
PS：查看方式：show variables like 'binlog_row_image'
默认是full：完整
记录修改行的全部内容
noblob：就是在full记录的基础上对大文本列的优化
没有对text或者blob列修改就不记录该列
minimal：简单记录，只记录修改的那一列
PS：这个要特别注意一点，虽然容量小了，但是一旦误操作，很难恢复的（不知道原来内容）
推荐使用一般使用binlog_format=mixed混合格式 or binlog_format=row + binlog_row_image=minimal
PS：如果对安全性要求特别高，推荐使用binlog_format=row + binlog_row_image=full（不怕误操作）
这个和SQLServer的日志恢复模式有点类似，我贴下图你们可以对比参考：
上面虽然说完了二进制日志的常用3种格式，但老版本默认都是不启用二进制日志的，咋办？
PS：如果是MariaDB可以去示例配置中查看：ls /usr/share/mysql/ |grep .cnf（CentOS）
验证下：
MySQL8之前：cat /etc/mysql/mysql.conf.d/mysqld.cnf（UbuntuServer）