Binlog
Binary log 二进制日志
mysql服务器的一本日记，记录
对数据库中数据的修改（insert,update,delete)
对数据表结构的修改(create table，update table)
常用作用:
主从复制时，主mysql服务器（master）将binlog发给从mysql服务器（slaver），从服务器执行binlog里面的事件，将自己的数据和主服务器保持同步
数据恢复:执行binlog里面的事件，将数据恢复到某个时间点的状态
binlog的三种模式：
描述 | // 更新数据表products UPDATE products SET price = 99.99 WHERE id = 123; | 优缺点 | |
statement模式下的binlog | 记录执行的原始sql语句 | # 日志位置: 556, 时间戳: 2023-10-27 10:00:00 UPDATE products SET price = 99.99 WHERE id = 123; | 优点: 占用磁盘空间少。 缺点: 如果SQL语句是不确定性的（例如，使用了 UUID() 或 NOW() 函数），在从库上执行可能会产生不同的结果 |
Row模式下的binlog | MySQL的默认格式,不记录SQL语句，而是记录被实际修改的数据行。对于一个 UPDATE 操作，它会记录“前镜像”（修改前的行数据）和“后镜像”（修改后的行数据） | 日志位置: 870, 时间戳: 2023-10-27 10:00:00 事件: Update_rows 数据库: my_store, 表: products 前镜像: id=123, name='Super Widget', price=89.99 后镜像: id=123, name='Super Widget', price=99.99 | 优点: 对于复制来说非常安全。 缺点: 如果一个查询更新了大量的数据行，可能会非常冗长，占用更多的磁盘空间。 |
mixed模式下的binlog | MySQL 会自动地为每一条执行的SQL语句选择最合适的日志格式。 | 对于绝大多数“安全”的、确定性的SQL操作（比如简单的 INSERT, UPDATE, DELETE），MySQL会默认使用 STATEMENT 格式来记录。因为这种格式最节省磁盘空间 遇到“不安全”操作时，自动切换到 ROW 格式：当MySQL判断一条SQL语句如果用 STATEMENT 格式记录，在从库上执行可能会产生与主库不同的结果时（即“不确定性”操作），它就会自动将这一条SQL语句的日志格式切换为 ROW 格式。（比如当SQL语句中包含 | 优点： 兼顾了 STATEMENT 模式的存储效率和 ROW 模式的安全性。 对于大部分常规操作，日志文件会比纯 ROW 模式小很多。 缺点： 不确定性：你无法100%预知下一条SQL会以哪种格式记录，这给日志解析和问题排查带来了一些复杂性。 MySQL需要花费额外的CPU周期去判断每条SQL是否“安全”，虽然这个开销很小。 |
虽然 MIXED 模式是一个很聪明的折中方案，但在今天的生产环境中，ROW 格式已经成为事实上的标准和默认推荐。主要原因有：
安全性压倒一切：ROW 格式提供了最高级别的数据一致性保证，杜绝了主从数据不一致的风险。
存储成本下降：相比于十几年前，现在的磁盘存储非常廉价，ROW 格式带来的额外空间开销已经不再是主要矛盾。
MIXED 模式是一个历史性的产物，它试图在性能和安全之间找到平衡。但在现代数据库实践中，为了追求极致的数据可靠性和运维的简单性，直接选择 ROW 格式是更明智、更普遍的做法。
代码中如何使用binlog？
让您的程序伪装成一个MySQL的从库。Go程序会连接到MySQL服务器，告诉它：“你好，我是一个从库，请从某个位置开始把你的Binlog事件发给我”，然后您的程序就可以处理源源不断发来的事件流了。