mysql中binlog三种模式

1. binlog的作用

Binlog(二进制日志)是MySQL服务器层维护的一种二进制格式的日志文件。它记录了所有的DDL(数据定义语言)语句和DML(数据操作语言)语句,但不包括数据查询语句(SELECT、SHOW等)。通俗的讲就是binlog值记录增删改，不记录查。

2. 三种模式说明

(1). Statement（基于SQL语句的复制，SBR）

Statement格式的binlog会记录每一项更改数据的SQL语句本身。这意味着每当主库上执行了一个数据修改操作，其对应的SQL语句就会被完整地记录在binlog中。
优点：

记录的内容相对简洁，不包含每一行具体的变化细节，因此可以减少binlog日志的大小，节省磁盘IO，提升性能。
缺点：

由于仅仅记录了SQL语句，为了在备库上精确重现主库的执行效果，还需要记录诸如session变量、用户定义变量等相关上下文信息，以防备库因环境差异而导致执行结果不同。
对于涉及特定存储过程、函数、触发器调用的情况，可能无法确保复制的一致性。

由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的 一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,像一些特定函数功能，slave可与master上要保持一致会有很多相关问题(如sleep()函数， last_insert_id()，以及user-defined functions(udf)会出现问题).

使用以下函数的语句也无法被复制：

• LOAD_FILE()

• UUID()

• USER()

• FOUND_ROWS()

• SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)

同时在INSERT …SELECT 会产生比 RBR 更多的行级锁

(2). Row（基于行的复制，RBR）

Row格式的binlog不再记录SQL语句，而是直接记录数据行级别的更改详情。

优点：

明确记录了每一行数据的修改细节，能精确反映数据变化，避免了SBR中可能出现的复制一致性问题。
即使在主从服务器的表结构稍有差异或者存在触发器、函数等情况，也能确保复制的正确性。
缺点：

由于需要记录每一行的具体修改，可能导致binlog日志量增大，占用更多存储空间，增加网络传输负担。
所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比 如一条update语句，修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大，特别是当执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。

(3). Mixed（混合模式复制，MBR）

Mixed格式则是对前两种格式的综合运用，MySQL会智能地根据执行的具体SQL语句选择合适的日志记录方式。

特点：

对于大多数常规SQL语句，MySQL会选择使用Statement格式记录binlog，以减少日志量。
当遇到那些在备库上直接执行原始SQL语句无法达到与主库相同效果的情况，如涉及不确定性的函数、存储过程、触发器等，MySQL会自动切换到Row格式，确保复制的准确性。

3.主从中的使用

其实选哪个模式主要看自己的需求，这里给出一个通解：首选 Mixed，优点比较明显，其次是row，准确度高一些，最后是Statement，毕竟谁也不想漏点什么。

参考文章：
https://blog.csdn.net/qq_29752857/article/details/136728483
https://www.cnblogs.com/sunlong88/p/9193986.html