异步复制对主库性能有可测但可控开销：binlog写入（受sync_binlog设置影响）、Dump线程CPU与网络负载、半同步启用或从库严重延迟时的间接拖慢，根因常在从库配置不当。
异步复制对主库性能有可测但通常可控的开销，不是“有没有影响”，而是“影响在哪、多大、怎么压”。
binlog 写入带来的 I/O 与事务延迟
主库所有 DML/DDL 都必须先写入 binlog 才能提交，这步绕不开。关键变量是 sync_binlog 设置：
- 设为
1：每次事务都fsync落盘，最安全，但磁盘慢时可能抬高commit延迟； - 设为
10或100：攒批刷盘，吞吐更高，RPO 略升（最多丢最近 N 个事务）； - 若主库用 NVMe 盘 + 合理
innodb_flush_log_at_trx_commit=1，sync_binlog=1的额外延迟常在 0.1–0.3ms 级别，监控Com_commit和Handler_commit可验证。
dump 线程的 CPU 与网络负载
每个活跃从库连上来，主库就起一个 Binlog Dump 线程——它不执行 SQL，只读 binlog 文件 + 发送网络包，但资源消耗真实存在：
- 1–5 个从库：CPU 占用通常
- 10+ 个从库且带宽紧张（如千兆内网跑 200MB/s 复制流）：
top可见mysqld进程 CPU 持续 >30%，netstat -s | grep "retransmitted"若重传增多，说明网络已成瓶颈； - 避免“僵尸从库”：长期不拉日志的从库会让主库保留旧
binlog文件，SHOW BINARY LOGS查看文件数是否异常增长，expire_logs_days必须设（推荐 7–14 天）。
锁竞争与半同步带来的间接拖慢
纯异步复制下，主库几乎不等从库，INSERT 性能基本不受影响。但两个场景会打破这个前提：
- 启用了
rpl_semi_sync_master_enabled=ON：主库需等至少一个从库ACK，若从库延迟或网络抖动，commit会被卡住——查show status like 'Rpl_semi_sync%'中Rpl_semi_sync_master_yes_tx和Rpl_semi_sync_master_no_tx比值，低于 95% 就该排查从库健康度； - 从库严重延迟 + 主库 binlog 积压：当
binlog文件轮转过快、清理不及时，FLUSH LOGS或purge binary logs可能触发锁表级操作，间接阻塞写入；这时SHOW PROCESSLIST里会出现Master has sent all binlog to slave; waiting for more updates之外的长时间Waiting for binlog to be written状态。
真正容易被忽略的是：性能损耗从来不是孤立发生的。一个配置不当的从库（比如没调 innodb_buffer_pool_size、开着 slow_query_log 写磁盘），会导致自身 SQL 线程卡顿，进而让主库 dump 线程堆积、网络缓冲区满、最终反向拖慢主库事务提交——问题表象在主库，根子却在从库。盯住 Seconds_Behind_Master 和主库 Threads_running 的联动变化，比单纯看 CPU 更早发现问题。
