首要确认sql_log_bin变量是否被临时关闭：该会话级开关设为off时，当前连接所有dml/ddl均不写入binlog，即使全局log_bin=on且binlog_format正常；常见于备份脚本执行set sql_log_bin=off后未恢复，导致后续操作无binlog记录。
mysql备份时binlog没有记录，首要确认sql_log_bin变量是否被临时关闭了。这个会话级开关一旦设为OFF，当前连接执行的所有DML/DDL都不会写入binlog，哪怕全局log_bin开着、binlog_format也正常——这是备份脚本或运维工具里最常被忽略的“静默失效”点。
为什么sql_log_bin=OFF会导致备份期间binlog空白
很多备份工具（比如某些自研脚本、Percona XtraBackup 的部分模式、甚至 mysqldump 加 --single-transaction 时配合特定权限）会在连接建立后立刻执行 SET sql_log_bin = OFF，目的是避免备份过程产生的内部语句（如临时表操作、XA事务协调等）污染主库 binlog。但若脚本没在备份结束后恢复它，或者连接复用未重置，后续人工操作就完全不记 binlog。
常见错误现象包括：
- 执行
SHOW BINARY LOGS;看到日志文件存在，但SHOW BINLOG EVENTS IN 'mysql-bin.0000xx' FROM N LIMIT 5;返回空或只有Rotate/Format_description - 主从复制延迟突增，且
SHOW SLAVE STATUS\G中Seconds_Behind_Master持续上涨，但Relay_Log_Space不增长 - 用
mysqlbinlog解析最新 binlog 文件，内容极少，甚至只含头部信息
如何快速检查并修复sql_log_bin状态
登录 MySQL 后直接查当前会话值：
SELECT @@sql_log_bin;
返回 0 就是关了；返回 1 是开着。注意：这仅反映当前连接状态，不是全局配置。
修复建议：
- 如果只是当前会话误关，执行
SET sql_log_bin = ON;即可立即恢复记录（无需重启） - 如果发现备份脚本里硬编码了
SET sql_log_bin = OFF，务必在其末尾补上SET sql_log_bin = ON;，或改用连接池自动重置机制 - 不要依赖
my.cnf配置项控制它——sql_log_bin是只读会话变量，不能在配置文件中设置 - 对关键业务账号，可在
init_connect里强制初始化：init_connect = "SET sql_log_bin = ON"（需确保该账号无 SUPER 权限，否则会被跳过）
sql_log_bin 和 log_bin 的关系容易混淆
两者完全独立：
-
log_bin是全局系统变量，决定 binlog 功能是否启用（SHOW VARIABLES LIKE 'log_bin';查） -
sql_log_bin是会话级开关，只影响当前连接的语句是否写入 binlog（SELECT @@sql_log_bin;查） - 即使
log_bin=ON，只要某连接的sql_log_bin=OFF，该连接所有变更都“隐身” - SUPER 权限用户可以随时切换自己的
sql_log_bin，普通用户不行（除非显式授权）
真正难排查的是：你看到的“备份后没 binlog”，往往不是配置没开，而是某个连接悄悄关掉了它，而且没人记得去开回来。
