log-bin必须配合server-id才能生效，单独配置log-bin无效；二者须同置于[mysqld]段下，server-id为1–255正整数，且目录权限需正确，否则binlog不启用。
log-bin 必须配合 server-id 才能生效
单独写 log-bin 不会启用二进制日志，MySQL 会静默忽略。必须在 [mysqld] 段下同时配置 server-id（值为 1–255 的整数），否则 SHOW VARIABLES LIKE 'log_bin' 仍显示 OFF。
常见错误现象：log_bin 变量为 OFF，SHOW MASTER STATUS 报错 ERROR 1378 (HY000): The server is not configured as a replication slave（实际是主配置缺失，不是从库问题）。
-
server-id在单机环境也必须设，不能留空或注释掉 - 路径建议用绝对路径，例如
log-bin = /var/lib/mysql/binlog/mysql-bin，避免和datadir混在一起 - 目标目录需提前创建，并确保 MySQL 进程用户（如
mysql）有读写权限，否则启动失败且错误日志里只提示Can't open log file
binlog_format=ROW 是安全底线，别用 STATEMENT
MySQL 8.0 默认仍是 STATEMENT（除非你用了某些云托管版本的定制镜像），但该格式在涉及 NOW()、UUID()、USER() 或自增列等非确定性函数时，会导致主从数据不一致——这不是概率问题，是必然风险。
ROW 格式记录的是行级变更，复制和恢复都可靠；代价是日志体积略大，但磁盘比数据一致性廉价得多。
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 不要依赖
MIXED自动切换：它在内部仍可能回退到STATEMENT，且行为难预测 - 确认生效后执行
SHOW VARIABLES LIKE 'binlog_format'，输出必须是ROW，不是row或小写 - 已运行的实例改格式后，新事务立即按新格式记录，旧 binlog 文件保持原格式不变
expire_logs_days 已被弃用，改用 binlog_expire_logs_seconds
MySQL 8.0.11+ 中 expire_logs_days 被标记为 deprecated，继续使用不会报错但会被忽略。必须改用 binlog_expire_logs_seconds（单位：秒）。
例如保留 7 天：写 binlog_expire_logs_seconds = 604800。不设置则默认 2592000 秒（30 天），但前提是 binlog_expire_logs_auto_purge 为 ON（默认就是）。
- 修改后无需重启，可动态执行
SET PERSIST binlog_expire_logs_seconds = 604800 - 手动清理用
PURGE BINARY LOGS BEFORE '2026-05-01 00:00:00'，注意时间格式必须是 DATETIME 字面量 - 如果磁盘突然爆满，优先检查
SHOW BINARY LOGS输出的文件数量和大小，而不是直接删文件
第一次写入后才生成 .000001 文件，别急着查
配置正确、服务重启成功后，SHOW MASTER STATUS 会返回初始位置（如 File: mysql-bin.000001, Position: 156），但此时磁盘上还不会有 mysql-bin.000001 文件——它只在第一个事务提交（INSERT/UPDATE/DELETE）后才真正落盘。
所以刚重启完立刻去 ls /var/lib/mysql/binlog/ 看不到文件，不等于没开成功。
- 执行一条
CREATE TABLE test_t(id INT) ENGINE=InnoDB就能触发生成 -
sql_log_bin=0会临时关闭当前会话的 binlog 记录，调试时有用，但别长期开着 - 确认是否真在写：监控
SHOW GLOBAL STATUS LIKE 'Com_insert'和Binlog_cache_use是否随操作递增
