sync_binlog=1是强一致性的底线，必须配合innodb_flush_log_at_trx_commit=1或2，确保binlog与innodb日志一致；设为0则复制链断裂，设为大于1会丢失事务，仅适用于可容忍秒级丢失的非核心场景。
sync_binlog=1 是强一致性的底线，不是可选项
主库一旦宕机，sync_binlog 决定从库能追到哪——设为 0 时，binlog 可能只在 OS 缓存里，主库断电后这部分日志就永远丢失，从库再也无法补齐。这不是“性能换安全”的权衡，而是“有没有复制链”的分水岭。sync_binlog=1 意味着每个 COMMIT 都调用 fsync() 写盘，保证 binlog 持久化，是 GTID 和基于位置复制能成立的前提。
- 必须配合
innodb_flush_log_at_trx_commit=1或=2，否则 InnoDB 日志和 binlog 可能不一致，导致崩溃恢复失败或主从数据错乱 - 不要只改
sync_binlog却忽略innodb_flush_log_at_trx_commit，两个参数必须协同生效 - 验证是否真正生效：
SHOW VARIABLES LIKE 'sync_binlog'返回值必须是 1，且不能是只读状态（某些云厂商会锁定该变量）
设成大于 1 的值，本质是用“丢事务”换吞吐
比如 sync_binlog=100，MySQL 会等满 100 个事务才刷一次盘。这确实降低 I/O 次数，但代价明确：主库突然宕机，最后最多 99 个已提交事务不会出现在 binlog 中，从库永远同步不到——这些事务对应用来说“已成功”，但实际没落盘。
- 常见错误现象：
Seconds_Behind_Master突然跳变归零，但SHOW SLAVE STATUS\G显示Exec_Master_Log_Pos停在某个旧位置，查主库SHOW MASTER STATUS发现对应位置的 binlog 已被截断或缺失 - 仅适用于可接受“秒级数据丢失”的业务场景，如实时推荐、用户行为埋点等非核心交易数据
- 数值不宜设得过大（如 1000+），否则单次刷盘压力陡增，反而引发 I/O 尖峰，造成写入抖动
sync_binlog=0 在生产环境等于放弃复制可靠性
sync_binlog=0 不是“延迟刷盘”，而是完全交由操作系统调度——binlog 可能在内存缓存中停留数秒甚至更久，期间任何断电、内核 panic 或强制 kill -9 都会导致这部分日志不可恢复。它唯一适合的场景是本地开发或压测临时实例。
- 云数据库（如阿里云 RDS、AWS RDS）通常禁止设置
sync_binlog=0，底层会强制覆盖为 1 - 即使搭配
binlog_group_commit_sync_delay，也无法弥补sync_binlog=0导致的日志丢失风险，两者解决的是不同层面的问题 - 监控项
Binlog_cache_disk_use和Binlog_cache_use与sync_binlog无关，别误以为调大缓存就能替代刷盘策略
SSD + 组提交才是真正的性能突破口
与其在 sync_binlog 上冒险降级，不如把 I/O 瓶颈真正解决掉。现代 SSD 配合组提交（binlog_group_commit_sync_delay + binlog_group_commit_sync_no_delay_count），能让多个事务的日志合并一次 fsync()，既保持 sync_binlog=1 的安全性，又大幅摊薄开销。
- 典型配置：
binlog_group_commit_sync_delay = 100000（0.1 秒等待） +binlog_group_commit_sync_no_delay_count = 10（凑够 10 个事务立即刷） - 必须确保主库使用 SSD 存储 binlog，且文件系统启用 write barrier（ext4/xfs 默认开启）
- 如果 binlog 路径和 innodb log file 在同一块磁盘上，即使设了
sync_binlog=1，I/O 争抢也会拖慢整体写入，务必分离路径
sync_binlog 的取值从来不是“要不要安全”，而是“在哪一层兜住风险”：硬件层（SSD+RAID）、系统层（write barrier）、MySQL 层（sync_binlog=1 + 组提交）、应用层（幂等+补偿）。漏掉任何一环，单独调低 sync_binlog 都只是把问题往后推。
