执行 SHOW VARIABLES LIKE 'log_bin'; 返回 ON 才表示 Binlog 真正启用；若为 OFF，需检查错误日志权限或路径问题，且 log_bin 为只读变量，必须重启生效。
如何确认 log_bin 是否已启用
MySQL 启动时是否开启 Binlog，不看配置文件有没有写 log_bin，而要看实际运行状态。很多用户改了 my.cnf 却没重启 MySQL，或者写错了路径导致启动失败回退到默认配置。
- 直接执行
SHOW VARIABLES LIKE 'log_bin';—— 返回ON才算真正生效 - 如果返回
OFF，检查错误日志（通常是/var/log/mysql/error.log或mysqld.err），常见报错是File '/var/lib/mysql/mysql-bin.index' not found (Errcode: 13 - Permission denied)，说明目录权限不对或路径不可写 -
log_bin是只读变量，运行时不能用SET GLOBAL log_bin = ON修改，必须重启 mysqld
log_bin 的路径和文件名怎么设才安全
不建议只写 log_bin = ON（MySQL 5.7+ 允许但隐式生成默认路径），因为默认会把日志写进数据目录，和 ibdata1 混在一起，既影响备份隔离，又可能因磁盘满导致主库宕机。
- 显式指定路径：例如
log_bin = /data/mysql/binlog/mysql-bin，注意末尾不带扩展名，MySQL 会自动加.000001等序号 - 确保
/data/mysql/binlog/目录存在、属主为mysql用户、有读写权限（chown mysql:mysql /data/mysql/binlog && chmod 750 /data/mysql/binlog） - 避免使用 NFS 或低 IOPS 的网络存储——Binlog 是顺序写密集型，挂载点延迟高会导致主库
commit变慢
选 ROW 还是 STATEMENT 格式？关键看业务写法
格式由 binlog_format 控制，不是“越详细越好”。ROW 虽然精确，但日志体积大、解析慢；STATEMENT 节省空间，但遇到 NOW()、UUID()、自增主键等非确定性函数会出问题。
- 只要用了
INSERT ... SELECT、触发器、存储过程、或任何含函数的写操作，一律用ROW - 纯简单 CRUD 且无时间/随机函数，
STATEMENT在从库重放更快，但现实中极少满足这个条件 -
MIXED是折中方案，但 MySQL 实际判断逻辑黑盒多，线上环境不如明确锁死为ROW省心 - 修改后需重启或执行
SET GLOBAL binlog_format = 'ROW';（仅对新连接生效，已有连接保持旧值）
为什么 expire_logs_days 不起作用？
这个参数在 MySQL 8.0 已废弃，换成 binlog_expire_logs_seconds。即使版本够老，它也只控制“自动清理”，不阻止日志写满磁盘。
- MySQL 5.7：设
expire_logs_days = 7，但若磁盘空间不足，binlog 仍会写失败并卡住所有写入 - MySQL 8.0+：必须用
binlog_expire_logs_seconds = 604800（7 天），且需配合binlog_space_limit（如 10G）做双重防护 - 更稳妥的做法是外置定时任务：每天跑
mysql -e "PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);"，并监控SHOW BINARY LOGS;的文件数量与总大小
Binlog 配置最易被忽略的，是日志路径的磁盘容量和权限隔离——它不像慢查询日志那样允许“写失败就丢弃”，一旦出问题，整个主库写入就停摆。
