mysql binlog文件真实存储格式和其各自的优缺点

STATEMENT：基于SQL语句的复制（statement-based replication, SBR）
ROW：基于行的复制（row-based replication, RBR）
MIXED：混合模式复制（mixed-based replication, MBR）

STATEMENT

是基于mysql的语句的存储
我在mysql 5.6的环境中执行了下面的语句

对应使用mysqlbinlog 解密对应的文件得到下面的文件
binlog中的文件与我执行的完全一致，所以STATEMENT是对执行的sql进行复制。

ROW

然后我在8.0继续执行上面的语句，得到的是如下的格式(5.7以后默认ROW)
主要是修改和删除，记录的是每个语句的变化，相对安全但是容量会大(如一个修改语句100个受到影响就会有100条，但是statement只有一个执行语句)

Mixed

一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则 采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式

从网上粘的。懒得测试，，感兴趣的可以深入测试

当 DML 语句更新一个 NDB 表时；
. 当函数中包含 UUID() 时；
. 2 个及以上包含 AUTO_INCREMENT 字段的表被更新时；
. 执行 INSERT DELAYED 语句时；
. 用 UDF 时；
. 视图中必须要求运用 row 时，例如建立视图时使用了 UUID() 函数；

优缺点抄的：
原文链接：https://blog.csdn.net/weixin_28736145/article/details/113260588

STATEMENT
优点：生成的日志量少，节约网络传输io；并不强制要求主从数据库的表定义完全相同；相比行的复制模式更为灵活

缺点：对于非确定性事件，无法保证主从复制数据的一致性；对于存储过程，触发器，自定义函数进行的修改也可能造成数据不一致；相比于基于行的复制方式在从上执行时需要更多的行锁

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

我理解的就是
优点：日志量少，节约网络传输io
缺点：对于存储过程，触发器可能造成数据不一致

ROW

优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下 每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题

缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比 如一条update语句，修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大，特别是当执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。

我理解的就是
优点：日志量全，对存储过程支持良好
缺点：数据量大，当表结构发生变化时，变动太大

Mixed — 没有了解，也没有地方给我抄

附-命令

是否开启binlog

show variables like '%log_bin%';

log_bin 是ON为开启

设置binlog开启
修改对应的my.cnf 或者window的my.ini
[mysqld]
log_bin=ON
记得重启

查看binlog_format

show variables like 'binlog_format'

获取binlog文件列表

show binary logs;

执行sql语句

CREATE TABLE `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_name` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL,
  `password` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL,
  `flag` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL,
  `status` varchar(255) COLLATE utf8mb4_bin DEFAULT NULL,
  `create_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;


INSERT INTO `test_log`.`user` (`id`, `user_name`, `password`, `flag`, `status`, `create_time`) VALUES (1, '李1', '李1', '李flag', '1', '2022-03-29 09:48:41');
INSERT INTO `test_log`.`user` (`id`, `user_name`, `password`, `flag`, `status`, `create_time`) VALUES (2, '李2', '李2', '2', '2', '2022-03-29 09:48:43');
INSERT INTO `test_log`.`user` (`id`, `user_name`, `password`, `flag`, `status`, `create_time`) VALUES (3, '李3', '李3', '3', '3', '2022-03-29 09:48:46');

update user SET flag = '1' WHERE user_name = '李3';

update user SET flag = '1' WHERE user_name like '%李%';

DELETE FROM user WHERE user_name like '%李%';

SHOW VARIABLES like '%log_bin%';

./mysqlbinlog -vv /usr/data/ON.000004 >end.log

./mysqlbinlog -vv /var/lib/mysql/binlog.000006 >end.log