MySQL 5.7+ 开启 binlog 必须同时配置 log-bin 和 server-id，且均置于 [mysqld] 段下；仅配 log-bin 不生效，重启后需用 SELECT @@log_bin 确认真值。
MySQL 5.7+ 开启 binlog 必须同时配置 log-bin 和 server-id
不配 server-id，MySQL 启动时不会报错，但 SHOW VARIABLES LIKE 'log_bin'; 返回 OFF，binlog 实际未生效。这是最常被忽略的隐性依赖。
原因很简单：MySQL 把 server-id 当作复制身份标识，而 binlog 是复制的基础——哪怕你当前不搞主从，只要没设 server-id，就默认禁用 binlog 写入。
-
log-bin值建议写绝对路径，比如/var/lib/mysql/mysql-bin（不带后缀），避免 MySQL 自行补全出错 -
server-id必须是正整数，主从环境中不能重复；单机调试可设为1，但生产环境建议用有意义的值（如101） - 配置项必须放在
[mysqld]段下，放错位置（比如[client]或文件末尾无段落标记）会导致完全不加载
修改 my.cnf 后必须重启 mysqld，SET PERSIST 不生效
binlog 是服务启动时初始化的模块，运行时无法动态开启。执行 SET PERSIST log_bin = ON; 会报错 Variable 'log_bin' is a read only variable。
常见误操作是改完配置、只执行 mysqladmin reload 或 FLUSH PRIVILEGES，结果日志还是没生成——这些命令不触发 binlog 初始化逻辑。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 确认配置已加载：启动后执行
SELECT @@log_bin, @@log_bin_basename, @@server_id;，三者都应有非空/非零值 - 检查物理文件是否生成：
ls -l /var/lib/mysql/mysql-bin.*（路径需与log-bin配置一致） - 如果仍为空，用
mysqld --defaults-file=/etc/my.cnf --verbose --help | grep "log-bin"验证配置文件是否被正确读取
log-bin 路径权限错误会导致启动失败且无明确提示
MySQL 进程用户（通常是 mysql）必须对 log-bin 指定的目录有写权限。若权限不足，mysqld 可能静默退出或卡在启动阶段，错误日志里只有一句模糊的 Can't open the mysql.plugin table 或直接无记录。
这不是 bug，是早期版本遗留的行为：binlog 初始化失败时，部分错误被吞掉，只留下底层 I/O 异常。
- 安全做法：创建专用目录，例如
sudo mkdir -p /var/lib/mysql-bin && sudo chown mysql:mysql /var/lib/mysql-bin - 然后在
my.cnf中设log-bin = /var/lib/mysql-bin/mysql-bin - 切勿复用
datadir目录做 binlog 存储——高并发写入可能引发 IO 争抢，影响主库性能
开启 binlog 后首次重启失败？检查 binlog_format 兼容性
MySQL 5.7 默认 binlog_format = ROW，但如果你是从 5.6 升级上来，或使用了某些 ORM（如旧版 Laravel 的 DB::statement()），可能遇到 Statement is not safe to log in statement format 类警告，严重时导致事务回滚或连接中断。
这不是配置错误，而是语句级日志（STATEMENT）和行级日志（ROW）对非确定性函数（如 NOW()、UUID()、自定义函数）处理方式不同。
- 临时绕过：启动前在
my.cnf加binlog_format = MIXED，让 MySQL 自动降级 - 长期方案：代码中避免在 UPDATE/INSERT 里用非确定性函数；或显式指定
binlog_format = ROW并接受更大数据量 - 注意：
binlog_format可动态设置，但仅对新连接生效，已有连接保持原格式
log-bin 和 server-id 都得有、都在 [mysqld] 下；重启后用 SELECT @@log_bin 看真值，别只信配置文件。其他问题基本是路径权限或格式兼容性在捣鬼。 
