开启binlog对主库性能影响仅约1%，真正瓶颈在于binlog_format、sync_binlog、binlog_cache_size等配置；生产必须用row格式、sync_binlog=1、合理调大缓存，并监控binlog_cache_disk_use与从库延迟。
开启 binlog 本身对主库性能影响极小，但配置不当会放大损耗
MySQL 官方实测数据：开启 log_bin 后，整体吞吐下降约 1%，属于可接受范围。真正拖慢主库的，从来不是“开没开 binlog”，而是日志格式、缓存大小、刷盘策略这些细节配置。
-
binlog_format=STATEMENT虽然日志体积小，但遇到NOW()、UUID()、自定义函数等非确定性语句时，从库执行结果可能和主库不一致——这不是性能问题，是数据一致性事故 - 生产环境必须设为
binlog_format=ROW，它记录每一行变更前后的镜像，杜绝逻辑错位，但日志量明显增大，尤其在ALTER TABLE或大批量UPDATE时，binlog_cache_size不够会触发磁盘临时文件写入（看状态变量binlog_cache_disk_use是否增长） -
sync_binlog=1表示每次事务都强制刷盘，RPO=0 的前提，但高并发写入下，磁盘 IO 成瓶颈；设为 0 或 1000 可提升吞吐，但主库宕机可能丢失最近若干事务
主库 CPU 和 IO 压力升高的真实原因
不是 binlog 本身吃资源，而是它暴露了原本被掩盖的瓶颈点。比如主库单线程 dump 日志 + 多从库并发拉取，binlog_dump 线程可能争抢 CPU；又或者 relay log 写入和 SQL 线程重放堆积，反过来通过网络 ACK 拖慢主库 commit 速度。
- 用
SHOW PROCESSLIST观察是否有长时间运行的Binlog Dump线程，特别是当从库网络卡顿或 SQL 线程延迟严重时 -
innodb_flush_log_at_trx_commit=1+sync_binlog=1组合，会让一次事务触发两次 fsync（redo + binlog），机械盘上极易成为写入瓶颈 - 跨机房部署时，主从间 TCP 连接频繁重传、带宽打满，会导致主库
binlog_dump线程阻塞在 send()，表现为State: Sending binlog event持续数秒以上
怎么验证你的 binlog 配置是否合理
别只看 log_bin=ON 就以为万事大吉。真正起作用的是那一组联动参数，它们共同决定日志怎么记、记多少、何时落盘。
- 检查核心组合：
SELECT @@binlog_format, @@sync_binlog, @@binlog_row_image, @@binlog_expire_logs_seconds;—— 生产必须是ROW、1、FULL、2592000（30天） - 查缓存使用情况：
SHOW GLOBAL STATUS LIKE 'binlog_cache%';若binlog_cache_disk_use显著大于 0，说明binlog_cache_size太小，建议从默认 32K 提到 1M～4M（视平均事务大小而定） - 用
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | head -20确认确实是 ROW 格式且含前后镜像，避免误配成MIXED后悄悄切回 STATEMENT
最容易被忽略的隐性成本：从库延迟反向拖累主库
很多人以为主库“提交即返回”就彻底无感，其实不然。当从库 SQL 线程积压严重，I/O 线程持续追不上，主库的 binlog_dump 线程会在发送缓冲区满时等待从库消费——这会导致主库事务提交变慢，尤其在 slave_compressed_protocol=ON 未启用、网络带宽紧张时更明显。
- 监控关键指标：
Seconds_Behind_Master不是唯一标准，更要盯Slave_SQL_Running_State是否长期卡在Reading event from the relay log - 从库开启
slave_parallel_workers > 0（MySQL 5.7+）并设slave_parallel_type=LOGICAL_CLOCK，可显著缓解单线程重放瓶颈 - 主库避免超大事务（如全表 UPDATE），这类操作会锁住 binlog dump 直到整个事务结束，期间其他从库连接全部排队
binlog_cache_disk_use 和 Slow_queries 是否同步上涨——这两个数字一齐跳，基本就是 binlog 缓存和慢查询互相喂养，形成恶性循环。
