sync_binlog=1是强一致性底线，必须配合innodb_flush_log_at_trx_commit=1或2；设为0则复制链断裂，设为大于1会丢失事务，仅适用于可容忍秒级丢失的非核心场景。
sync_binlog 设为 0 还是 1？先看业务一致性要求
sync_binlog 决定 Binlog 是否在每次事务提交时强制刷盘。设为 0 性能最好，但崩溃后可能丢失最多一个事务的 Binlog；设为 1 保证强一致性，代价是每次提交都触发一次 fsync，IO 压力明显上升。
实操建议：
- 金融、支付类业务必须设
sync_binlog = 1，否则主从数据不一致风险不可接受 - 普通读多写少业务（如内容平台），可设
sync_binlog = 100或1000，用吞吐换少量数据丢失容忍度 - 别盲目设
sync_binlog = 0—— MySQL 5.7.7+ 默认开启innodb_support_xa，此时sync_binlog = 0会导致两阶段提交失效，Binlog 和 Redo 日志节奏脱钩，崩溃恢复可能失败
binlog_group_commit_sync_delay 怎么调才不卡住小事务
这个参数控制组提交的“攒批”等待时间（单位：微秒），不是毫秒。默认值 0 实际等于关闭组提交逻辑，高并发下大量线程卡在 Writing to binlog 状态，本质是每个事务都单独走 write + fsync。
实操建议：
- MySQL 5.7.28+ / 8.0.14+ 才真正支持微秒级 delay；旧版本设非 0 值会被截断为 0，白配
- 起步值建议
100（即 0.1ms），观察SHOW GLOBAL STATUS LIKE 'Binlog_group_commit_trigger_delay'是否明显上升 - 超过
500会显著拖慢短事务延迟，尤其对响应敏感型服务（如实时订单）不友好 - 配合
sync_binlog = 1使用才有意义；单线程压测永远看不到效果——必须有真实并发写入
binlog_cache_size 太小会让大事务掉进磁盘陷阱
MySQL 把事务的 Binlog 先缓存在内存里，等提交再刷盘。默认 32K 对批量导入、日志归档类大事务完全不够，缓存溢出后会写临时文件，I/O 成倍放大。
实操建议：
- 查当前使用情况：
SHOW STATUS LIKE 'binlog_cache%'，重点看binlog_cache_disk_use是否 > 0 - 按事务平均 Binlog 体积估算：比如 10 万行 INSERT，每行约 200 字节，总 Binlog 约 20MB → 设
binlog_cache_size = 20971520 - 该变量是会话级，
SET SESSION binlog_cache_size = 20971520只影响当前连接；全局生效需改配置文件或用SET PERSIST（MySQL 8.0+） - 别设成 1GB —— 过大会浪费内存，且没收益；够用就行
ROW 格式下别漏配 binlog_row_image=MINIMAL
默认 binlog_row_image = FULL，UPDATE/DELETE 操作会记录整行旧值和新值，Binlog 体积翻倍甚至更多，直接加剧网络传输、磁盘写入、从库回放压力。
实操建议：
- 生产环境一律设
binlog_row_image = MINIMAL，只记录变更列和主键（或唯一非空索引）字段 - 必须确保表有主键或唯一非空索引，否则
MINIMAL模式下从库无法定位行，复制会失败 - 修改后无需重启，动态生效：
SET GLOBAL binlog_row_image = 'MINIMAL' - 验证是否生效：
mysqlbinlog -v查看 event 内容，对比前后 Binlog 文件大小变化
最容易被忽略的是参数协同性：比如 sync_binlog = 1 但 innodb_flush_log_at_trx_commit = 2，Redo 刷盘节奏远快于 Binlog，组提交根本凑不齐“一批”，等于白调。所有 Binlog 优化都得放在主从一致性、崩溃恢复能力、业务容忍度这个三角里权衡，不是越快越好。
