MySQL二进制日志（binlog）是MySQL服务层生成的日志文件，记录了所有对数据库进行更改的操作，比如数据的增删改、表结构的变更等，查询操作不会被记录到二进制日志中。它是实现主从复制、数据恢复等核心功能的基础，合理管理二进制日志对数据库的稳定运行至关重要。
二进制日志的开启与基础配置
默认情况下MySQL可能没有开启二进制日志，需要在配置文件中进行设置。以Linux系统下的MySQL为例，修改my.cnf配置文件，添加如下配置项：
[mysqld] # 开启二进制日志，log_bin指定日志文件的基础名称，生成的文件会以该名称加序号和扩展名 log_bin=mysql-bin # 设置服务器ID，主从复制场景下每个节点的server_id必须唯一 server_id=1 # 设置二进制日志的格式，可选值有STATEMENT、ROW、MIXED binlog_format=ROW # 设置单个二进制日志文件的最大大小，默认是1G max_binlog_size=1073741824
修改完成后重启MySQL服务，即可开启二进制日志功能。可以通过如下SQL语句查看二进制日志是否开启：
-- 查看log_bin变量的值，ON表示已开启 SHOW VARIABLES LIKE 'log_bin';
查看二进制日志相关信息
可以通过以下SQL语句查看当前所有的二进制日志文件列表：
-- 查看所有二进制日志文件 SHOW BINARY LOGS;
如果需要查看某个二进制日志文件的具体内容，可以使用mysqlbinlog工具，该工具是MySQL自带的二进制日志解析工具，基本使用方式如下：
# 解析指定路径的二进制日志文件，输出为可读的文本格式 mysqlbinlog /var/lib/mysql/mysql-bin.000001
也可以在MySQL客户端内查看当前正在写入的二进制日志文件以及写入位置：
-- 查看当前二进制日志的状态 SHOW MASTER STATUS;
二进制日志的清理策略
二进制日志会持续生成，如果不及时清理会占用大量磁盘空间，需要设置合理的清理策略。常见的清理方式有两种，一种是自动清理，一种是手动清理。
自动清理配置
可以通过设置expire_logs_days参数来指定二进制日志的自动保留天数，超过指定天数的二进制日志会被自动删除。修改配置文件添加如下配置：
[mysqld] # 二进制日志保留7天，超过7天的日志会自动删除 expire_logs_days=7
也可以在线修改该参数，不需要重启MySQL服务：
-- 在线设置二进制日志保留天数为7天 SET GLOBAL expire_logs_days = 7;
手动清理方式
如果需要立即清理二进制日志，可以使用如下SQL语句：
-- 删除所有二进制日志，并重新生成新的日志文件，日志序号从000001开始 RESET MASTER; -- 删除指定日志文件之前的所有二进制日志，比如删除mysql-bin.000003之前的所有日志 PURGE BINARY LOGS TO 'mysql-bin.000003'; -- 删除指定时间之前生成的所有二进制日志，比如删除2024-05-01 00:00:00之前的所有日志 PURGE BINARY LOGS BEFORE '2024-05-01 00:00:00';
二进制日志的常见使用场景
二进制日志最主要的用途是主从复制和数据恢复。在主从复制场景中，主库将二进制日志发送给从库，从库重放这些日志中的操作，从而实现和主库的数据同步。在数据恢复场景中，可以先恢复全量备份，再通过二进制日志重放全量备份之后的所有数据变更操作，实现数据的增量恢复。
需要注意的是，在进行数据库全量备份时，如果使用了mysqldump工具，可以添加--flush-logs参数，在备份开始时刷新二进制日志，这样备份之后的所有变更都会记录到新的二进制日志文件中，方便后续的数据恢复操作。
# 备份test数据库，同时刷新二进制日志 mysqldump -u root -p --flush-logs test > test_backup.sql
二进制日志管理的注意事项
- 不要随意删除正在使用的二进制日志，尤其是主从复制场景中，从库可能还在读取旧的二进制日志，误删会导致主从复制中断。
- 二进制日志的格式选择需要根据业务场景决定，ROW格式能记录每一行数据的变更，可靠性更高，但日志量相对较大；STATEMENT格式记录SQL语句，日志量小，但部分函数可能无法正确复制。
- 定期监控二进制日志的磁盘占用情况，避免因为日志过大导致磁盘空间不足，影响MySQL服务的正常运行。