mysql 8.0 默认不开启 binlog，需显式配置 server-id=1 等参数并重启服务，仅靠 log_bin 默认启用但无 server-id 时会静默禁用；验证须执行 show binary logs 成功返回日志文件，而非仅看 select @@log_bin。
确认 MySQL 8.0 是否已启用 binlog
MySQL 8.0 默认不开启二进制日志（binlog），即使你装的是社区版或企业版。直接执行 SHOW VARIABLES LIKE 'log_bin';，如果返回 OFF 或空结果，说明还没开——这不是 bug，是默认安全策略。
别急着改配置，先检查当前用户是否有 REPLICATION BINARY LOG ADMIN 权限（启用后管理 binlog 所需），否则后续可能无法执行 FLUSH BINARY LOGS 或查看 SHOW BINARY LOGS。
修改 my.cnf 启用 binlog 的关键配置项
必须在 MySQL 启动前配置，运行时无法通过 SET GLOBAL 开启 log_bin（会报错 Variable 'log_bin' is a read only variable）。
编辑 /etc/my.cnf（Linux）或 my.ini（Windows），在 [mysqld] 段落下添加以下几行：
log_bin = mysql-bin binlog_format = ROW server_id = 1 expire_logs_days = 7 max_binlog_size = 100M
注意点：
-
log_bin值不能带路径（如/var/lib/mysql/mysql-bin）——MySQL 会自动加.index和序号，写绝对路径反而导致启动失败 -
server_id必须设为非 0 整数，主从复制场景下必须全局唯一；单机也要设，否则log_bin可能被忽略 -
binlog_format推荐用ROW，STATEMENT在函数、时间相关语句下易出错，MIXED行为不易预测 -
expire_logs_days和max_binlog_size不设也行，但不设会导致磁盘被撑爆，尤其高写入场景
重启 MySQL 并验证 binlog 是否生效
改完配置后必须重启服务：sudo systemctl restart mysqld（Linux）或通过服务管理器重启（Windows）。
重启后登录 MySQL 执行：
SHOW VARIABLES LIKE 'log_bin'; SHOW VARIABLES LIKE 'binlog_format'; SHOW BINARY LOGS;
如果 log_bin 显示 ON，且 SHOW BINARY LOGS 返回至少一个文件（如 mysql-bin.000001），说明成功。若仍为 OFF，检查错误日志：/var/log/mysqld.log 或 mysqld.err，常见报错包括：
-
Failed to open log file: Permission denied→ MySQL 用户对datadir目录无写权限 -
Unknown system variable 'log_bin'→ 配置写到了[client]段落，而非[mysqld] -
Server id not set→server_id缺失或为 0
开启后立即要注意的兼容性问题
启用 binlog 后，某些操作行为会变化，容易踩坑：
- 执行
CREATE TABLE ... SELECT时，如果源表有自增列，ROW格式下可能触发Statement violates GTID consistency错误（尤其在enforce_gtid_consistency=ON时）——得拆成CREATE TABLE+INSERT ... SELECT - 临时表（
CREATE TEMPORARY TABLE）在ROW格式下不记 binlog，但STATEMENT下会记，这点常被忽略 - DDL 语句（如
ALTER TABLE）在ROW格式下也会写入 binlog，但内容是“事件级”而非 SQL 文本，用mysqlbinlog解析时看到的是Table_map_event+Write_rows_event，不是原始 SQL
binlog 文件本身不可手动删除（哪怕用 rm），必须用 PURGE BINARY LOGS 或 RESET MASTER；否则 MySQL 启动时会校验 index 文件和实际文件一致性，缺失文件直接报错退出。
