应显式设置 binlog_format = ROW，因其保障主从一致性与DML可回放性；sync_binlog = 1 仅保证 binlog 不丢失，需搭配 innodb_flush_log_at_trx_commit = 1 才实现 crash-safe；expire_logs_days 需配合 FLUSH LOGS 或 max_binlog_size 使用以防堆积。
binlog_format 设置成 ROW 还是 STATEMENT？
MySQL 的 binlog_format 直接影响主从一致性、DML 可回放性，以及某些函数（如 NOW()、UUID()）在从库的行为。默认值在 8.0 是 ROW，5.7 是 STATEMENT，但线上应显式设为 ROW。
原因很简单：STATEMENT 格式下，像 UPDATE t SET c = RAND() WHERE id = 1 这类语句，在从库重放时会生成不同值；而 ROW 格式记录的是“哪几行变了”，不依赖上下文执行逻辑。
- 用
SET GLOBAL binlog_format = 'ROW'临时生效（重启失效） - 永久生效必须写进配置文件：
binlog_format = ROW，放在[mysqld]段下 - 注意：部分旧应用依赖 STATEMENT 格式下的日志可读性，改之前先确认是否有 binlog 解析工具或审计系统依赖 SQL 文本
- 混合模式（
MIXED）看似折中，但实际行为难预测，不建议生产使用
sync_binlog = 1 就一定安全？
sync_binlog 控制 binlog 文件写入磁盘的频率，设为 1 表示每次事务提交都调用 fsync() 刷盘——这是保证 crash-safe 的最低要求，但代价是 I/O 压力明显上升。
常见误判是以为开了 sync_binlog = 1 就万无一失。其实它只保障 binlog 不丢，**不等于主从数据强一致**。如果主库 crash 后立即重启，而从库还没拉到最新 binlog，就可能出现“主库有、从库没”的情况。
- 若写入压力大，可权衡设为
sync_binlog = 100（每 100 个事务刷一次），但需接受最多丢失最近 99 个事务的 binlog - 搭配
innodb_flush_log_at_trx_commit = 1才构成完整 crash-safe 配置，缺一不可 - 云数据库（如 RDS）常默认关闭
sync_binlog或设为 0，因底层存储已做持久化，此时修改前要查清厂商文档
binlog 自动清理靠 expire_logs_days 还是 purge？
expire_logs_days 是最常用的自动清理方式，但它的触发时机容易被忽略：MySQL 只在**每次启动、binlog 切换、或执行 FLUSH LOGS 时**检查并删除过期文件。这意味着如果实例长期不重启、也不切 binlog，老文件可能堆积数月不清理。
更可靠的做法是主动控制，尤其在磁盘空间敏感或需要精确保留天数的场景。
- 设
expire_logs_days = 7是基础，但必须配合定期执行FLUSH LOGS或让 MySQL 自动切换（比如用max_binlog_size限制单个文件大小） - 手动清理更可控：
PURGE BINARY LOGS BEFORE '2024-06-01 00:00:00'或PURGE BINARY LOGS TO 'mysql-bin.000123' - 注意：PURGE 命令会阻塞后续 DDL/DML，大实例建议在低峰执行；且执行前务必确认从库已拉取完毕，可用
SHOW SLAVE STATUS\G中的Relay_Master_Log_File对比 - 备份脚本里别只依赖
expire_logs_days，最好加一行PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY)
调整后怎么验证配置真生效了？
改完配置文件、重启 MySQL，不代表设置就落地了。很多问题出在“以为改了，其实没生效”——比如配置写错段落、权限不足导致 mysqld 忽略配置、或者变量被动态 SET 覆盖。
必须用运行时命令交叉验证：
- 查当前值：
SELECT @@global.binlog_format, @@global.sync_binlog, @@global.expire_logs_days; - 确认 binlog 是否开启：
SHOW VARIABLES LIKE 'log_bin';（返回 ON 才有效） - 看当前 binlog 文件列表和时间：
SHOW BINARY LOGS;，对比文件名和File_size是否符合预期（比如设了max_binlog_size = 1073741824，那多数文件应接近 1G） - 模拟写入后观察磁盘变化：用
INSERT INTO t VALUES (1); COMMIT;触发一次事务，再立刻ls -lh /var/lib/mysql/mysql-bin.*，看新文件是否及时生成、大小是否增长
真正麻烦的不是参数怎么写，而是改完之后没人去盯日志文件增长节奏、没人核对从库 IO 线程是否卡在某个 file position、也没人检查 SHOW MASTER STATUS 的 File 和 Position 是否还在推进——这些才是线上 binlog 配置有没有起效的硬指标。
