sync_binlog=1是常见抖动源，每次事务提交强制fsync，易引发I/O毛刺；建议设为100或配合innodb_flush_log_at_trx_commit=2使用，兼顾性能与一致性。
binlog刷盘太激进：sync_binlog=1 是常见抖动源
MySQL主库写入时，sync_binlog 控制二进制日志落盘频率。设为 1 表示每次事务提交都强制 fsync() 到磁盘，对 SSD 尚可承受，但对 HDD 或高并发写场景极易引发 I/O 毛刺——表现为 iostat -x 1 中 %util 短时飙高、await 波动剧烈。
真实生产中更稳妥的折中是设为 100（每 100 次事务合并一次刷盘），或结合 innodb_flush_log_at_trx_commit=2 使用；若必须强一致性，应确认存储层支持原子写（如 XFS + barrier）并避开云厂商虚拟块设备的隐式缓存陷阱。
-
sync_binlog=0：依赖操作系统缓存，崩溃可能丢 binlog，主从不一致风险高 -
sync_binlog=1：最安全但抖动最明显，尤其在批量导入或大事务场景 -
sync_binlog=N（N>1）：需配合监控Binlog_cache_use和Binlog_cache_disk_use，避免缓存溢出降级到临时文件
redo log与binlog双刷冲突：innodb_flush_log_at_trx_commit=1 + sync_binlog=1
当 innodb_flush_log_at_trx_commit=1（默认）与 sync_binlog=1 同时启用，InnoDB redo log 和 server 层 binlog 会各自触发一次 fsync()，两次物理写可能落在同一磁盘队列上，形成「双写争抢」。这不是 bug，而是设计使然——但会导致单事务 I/O 延迟翻倍，尤其在机械盘或低配云盘上表现突出。
解决思路不是关掉一致性，而是错开节奏：innodb_flush_log_at_trx_commit=2（redo 日志仅 write，不 fsync）+ sync_binlog=1，牺牲极小概率的崩溃丢失（最多 1 秒事务），换来 I/O 平滑度显著提升。
- 两者都为
1：强一致，但磁盘抖动概率最高 - 前者为
2，后者为1：多数业务可接受，抖动大幅缓解 - 两者都为
0：完全不可靠，仅限测试环境
binlog 文件滚动太频繁：max_binlog_size 设得太小
max_binlog_size 决定单个 binlog 文件最大体积。设为 100M 甚至 50M 会导致高频轮转：每写满就关闭旧文件、新建文件、更新索引文件 mysql-bin.index，并触发一次 fsync()。这种元数据操作本身轻量，但叠加大量小事务写入时，会放大磁盘寻道和日志头更新开销。
建议值按写入吞吐估算：若日均 binlog 增长 2GB，设 max_binlog_size=1G 更合理；同时配合 expire_logs_days=7 控制总量，避免磁盘被长期累积的旧 binlog 占满。
- 过小（如
10M）：轮转频繁，SHOW BINARY LOGS输出行数暴涨，影响purge binary logs效率 - 过大（如
10G）：故障恢复时 relay log 解析耗时增加，且单文件损坏影响面扩大 - 注意：该参数是动态变量，但修改后仅对新生成的 binlog 生效，已有文件大小不变
GTID 模式下 gtid_purged 不及时清理
开启 gtid_mode=ON 后，gtid_purged 记录已被清除的 GTID 集合。若长期未执行 PURGE BINARY LOGS，gtid_purged 字符串会持续膨胀（尤其在频繁创建/删除数据库的场景）。虽然它本身不写磁盘，但每次 SHOW MASTER STATUS 或复制握手时，MySQL 都需解析这个长字符串，CPU 解析开销会上升，间接加剧 buffer pool 压力，诱发脏页刷新抖动。
真正危险的是：当 gtid_purged 膨胀到几 MB，而 max_allowed_packet 未同步调大，复制连接建立阶段可能因协议包截断直接失败，错误日志里出现 Got fatal error 1236 from master ——这看似网络问题，实为元数据失控。
- 定期执行
PURGE BINARY LOGS BEFORE 'yyyy-mm-dd hh:mm:ss'，再查SELECT @@global.gtid_purged确认精简 - 不要手动 SET
gtid_purged，除非你清楚自己在重置复制起点 - 监控
gtid_purged长度：超过 10KB 就该预警
sync_binlog + innodb_flush_log_at_trx_commit + max_binlog_size 三者组合在特定负载下的共振效应。调参前先用 pt-ioprofile 或 iotop -p $(pgrep mysqld) 锁定真实 I/O 热点，比盲目改配置更有效。 
