在 MySQL 5.7 及更高版本中开启 binlog（二进制日志）有一条硬性规则：log_bin 和 server_id 必须同时配置，二者缺一不可。如果只设置了 log_bin 就想让二进制日志正常运转？那是不可能的。重启后执行 SELECT @@log_bin 依然会返回 0，日志文件根本不会生成。很多人在这一步就卡住了，反复检查配置文件，却始终找不到问题所在。
为什么修改了 my.cnf 还是无法生成 binlog 文件
最常见的原因是漏掉了 server_id 这个参数。MySQL 将 server_id 视为复制身份的标识——即使你只是单机运行，完全没有做主从复制的打算，只要 server_id 没有设置，binlog 写入就会被默认禁用。这一点没有任何商量余地。
server_id必须是正整数（比如1、101），不能是0，也不能留空；- 配置必须放在
[mysqld]段下方，如果放错位置（例如误放到[client]段里），整个配置根本不会被加载； log_bin的值建议使用绝对路径（例如/var/lib/mysql/mysql-bin），不要加后缀；在 Windows 下请使用正斜杠或双反斜杠，避免路径解析错误；- MySQL 进程的运行用户（通常是
mysql）必须对log_bin指向的目录拥有写入权限，否则启动时可能静默失败，不会给出任何明显错误提示。
Linux 下修改 my.cnf 后如何确认配置生效
重启只是第一步，关键在于确认以下三点是否全部到位：
- 执行
SELECT @@log_bin, @@log_bin_basename, @@server_id;——这三个值都应为非空、非零； - 运行
SHOW BINARY LOGS;，如果能列出具体的文件名，才说明物理日志已经开始写入； - 检查磁盘路径：
ls -l /var/lib/mysql/mysql-bin.*（路径必须与log_bin的配置保持一致）； - 如果结果依然为空，可以执行
mysqld --defaults-file=/etc/my.cnf --verbose --help | grep "log-bin"来核实配置文件是否真的被正确读取。
Windows 下路径与权限容易踩的坑
Windows 用户经常在路径创建和权限设置上遇到麻烦，以下是几个常见陷阱：
log_bin="C:/ProgramData/MySQL/MySQL Server 5.7/logs/mysql-bin"——该目录必须提前手动创建，MySQL 不会自动为你建立多级目录；- 确保 MySQL 服务的运行账户（默认是
LocalSystem或你指定的用户）对该目录拥有“写入”权限，否则服务启动会失败，错误日志中只有一句非常模糊的提示； my.ini文件的编码必须是 ANSI 或 UTF-8 无 BOM，否则 MySQL 可能会直接跳过整个配置段；- 千万不要用
mysqladmin reload或FLUSH PRIVILEGES来代替重启——binlog 是在启动时初始化的模块，运行时无法动态开启。
binlog_format 和 sync_binlog 该如何选择
binlog_format=ROW 已经成为当前的事实标准。特别是在涉及函数、触发器、时间字段等场景时，STATEMENT 格式很容易导致主从数据不一致。而 sync_binlog=1 可以保证事务提交时立即刷盘，代价是略微降低吞吐量。
- 在单机开发调试时，可以先设置
binlog_format=ROW+sync_binlog=0，在安全性与性能之间找到一个平衡点； - 生产环境建议使用
sync_binlog=1，特别是与innodb_flush_log_at_trx_commit=1配合使用； expire_logs_days=7或binlog_expire_logs_seconds=604800必须配置，否则日志文件会无限增长，最终撑满磁盘。
归根结底，binlog 真正生效依赖于配置加载、权限设置和路径正确这三个环节同时满足。任何一环断裂，log_bin 都只是一个摆设。不要只盯着 SQL 命令的返回值，一定要去文件系统里查看真实的日志文件是否存在。
