前言

MySQL的二进制日志binlog可以说是MySQL最重要的日志，它记录了所有的DDL和DML语句（除了数据查询语句select），以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。（需要注意的一点是，即便update操作没有造成数据变化，也是会记入binlog。）
一般来说开启binlog日志大概会有1%的性能损耗。

DDL：主要的命令有create、alter、drop等，ddl主要是用在定义或改变表(table)的结构,数据类型，表之间的连接和约束等初始工作上，他们大多在建表时候使用。
DML：主要命令是slect,update,insert,delete,就像它的名字一样，这4条命令是用来对数据库里的数据进行操作的语言

binlog有两个常用的使用场景

主从复制：mysql replication在master端开启binlog,master把它的二进制日志传递给slaves来达到master-slave数据一致的目的。
数据恢复：通过mysqlbinlog工具来恢复数据。

常用的binlog日志操作命令

查看所有binlog日志列表 【show master logs;】

查看master状态，即最后（最新）一个binlog日志的编号名称，及其最后一个操作事件pos结束点(Position)值。【show master status;】

flush 刷新log日志，自此刻开始产生一个新编号的binlog日志文件;【flush logs;】

注意：每当mysqld服务重启时，会自动执行此命令，刷新binlog日志；在mysqlddump备份数据时加-F选项也会刷新binlog日志；

重置（清空）所有binlog日志 　【reset master;】

binlog文件

MySQL5.1版本之前，binlog的记录格式都是基于SQL语句的statement格式。5.1版本后开始引入binlog_format参数，该参数可设的值也增加到了3种：statement，row，mixed.

statement：基于 SQL 语句的复制。

优点：binlog日志量占用小，节约了IO，提高性能。
缺点：对一些系统函数不能准确复制或不能复制，如now()、uuid()等。

row：基于行的复制，记录每行实际数据的变更。

优点：复制过程准确，不会出现某些特定情况下的存储过程，函数，以及触发器的调用和触发无法被正确复制的问题。
缺点：大量增加binlog的磁盘占用，在一些大表中清除大量数据时在 binlog 中会生成很多条语句，可能导致从库延迟变大。

mixed：在该模式下，MySQL会根据执行的每一条具体的sql语句来灵活选择记录格式。一般的语句修改使用statment格式来提高性能，在遇到一些statement无法完成主从复制的操作时，则采用row格式保存binlog。

优点：综合其他两种模式的特点，准确性强，文件大小适中。
缺点：可能导致主从不一致。

binlog与redolog的区别

binlog 是 MySQL 的 Server 层实现的，所有的引擎都是可以的	redo log 是 InnoDB 引擎特有的
binlog 是逻辑日志，比如” 给 id = 2 这一行的 c 字段加 1”	redo log 是物理日志，记录的是”在 XXX 页上做了 XXX 修改”
binglog 是事务提交的时候一次性写入	数据首先会被\写入到redolog buffer，事务每次提交都会将 redo log buffer 中的日志写入 os buffer 并调用 fsync() 刷到 redo log file 中
binlog 是可以追加写入的	redo log 是有固定大小的，所以它的空间会用完，如果用完的话，一定要进行一些写入磁盘的操作才可以继续

binlog与redolog一致性问题：2PC

1. 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
2. 执行器拿到引擎给的行数据，把这个值加上1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
3. 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare状态。然后告知执行器执行完成了，随时可以提交事务。 【写入 redo log（处于 prepare 阶段）】
4. 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。【写 binlog】
5. 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。【提交事务（处于 commit 状态）】

Mysql的两阶段提交

上面的流程采用了两阶段提交，那为什么要采用两阶段提交呢？是为了让 binlog 和 redo log 之间的逻辑一致。

我们假设一下上面的 update 语句在执行的每个时刻，MySQL 崩溃了，看一下两个日志间的逻辑是如何保持一致的。
假设在步骤3前，MySQL崩溃重启，那么事务提交失败，不会影响数据。虽然更新了内存，但崩溃后，内存会丢失。
假设在步骤3完成后崩溃，此时已经写入 redo log 了，重启后，发现 redo log 处于 prepare 阶段，就不恢复。
假设在步骤4完成后崩溃，此时已经写入 binlog 了，重启后，发现 binlog 已经写入了，就把对应的 redo log 改为 commit 状态。
这样就能保证 redo log 和 binlog 的逻辑一致性。

两阶段提交是跨系统维持数据逻辑一致性时常用的一个方案。

常用的binlog日志操作命令：https://blog.csdn.net/sinat_32430939/article/details/121533785
区别：https://blog.csdn.net/qq_45243783/article/details/125040675
一致性问题：https://blog.csdn.net/yzx3105/article/details/130685375