log_slave_updates=ON后，从库将复制事件写入本地binlog，导致I/O压力倍增；它本质是拓扑声明而非性能参数，仅在需级联复制、GTID切换或逻辑备份时启用，否则应保持默认OFF。
log_slave_updates 开启后写 binlog 增加 I/O 压力
从库开启 log_slave_updates = ON 后，所有从主库复制过来的事件（INSERT/UPDATE/DELETE 等）都会被重新写入本地 binlog 文件。这相当于把一次写操作变成两次：主库写一次，从库再写一次。尤其在高并发写场景下，I/O 负载会明显上升。
常见现象包括：iotop 显示 mysqld 进程持续高 write，iostat -x 1 中 %util 接近 100%，磁盘响应时间（await）飙升。
- 默认关闭时，从库只执行 relay log，不落盘 binlog；开启后，每个事务都要额外 fsync 到 binlog 文件
- 如果
sync_binlog = 1，每事务强制刷盘，性能折损更显著（尤其机械盘或低配 SSD） - 即使
sync_binlog = 0，binlog 缓冲区仍需频繁 flush，对内存和 CPU 也有额外开销
log_slave_updates 不是“开关式”优化项，而是拓扑决策点
log_slave_updates 的本质不是性能调优参数，而是复制拓扑的声明：它表示“这个从库是否参与下一级复制”。误开它，等于让本不该承担中继角色的节点强行背负中继职责。
典型误用场景：
- 纯读写分离架构中，从库只服务查询，却配置了
log_slave_updates = 1 - 高可用切换工具（如 MHA）未要求该从库做级联源，但人为开启了该参数
- 备份节点被临时当作新主库提升，但未提前开启
log_bin和log_slave_updates，事后补开导致同步卡顿
一旦开启，就需配套管理 binlog 生命周期（expire_logs_days）、监控磁盘增长、评估网络带宽（下游从库拉取该 binlog 时流量翻倍）。
性能下降是否真由 log_slave_updates 引起？先排除干扰项
直接归因于 log_slave_updates 容易忽略其他共存问题。实际排查时，应确认以下几点：
-
SHOW SLAVE STATUS\G中Seconds_Behind_Master是否持续增长？若为 0，说明 SQL Thread 没卡住，性能瓶颈可能不在复制链路本身 - 对比开启前后
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_wait_free'和'Threads_created'，判断是否内存或连接池不足 - 检查是否同时启用了
binlog_format = ROW+ 大字段更新 —— 这会让单条事件体积暴涨，放大log_slave_updates的写入负担 - 确认没顺手改错其他参数，比如把
innodb_flush_log_at_trx_commit = 1和sync_binlog = 1同时设上，形成双重刷盘压力
不开 log_slave_updates 也能支持主从切换，但必须提前准备
很多团队以为“不开 log_slave_updates 就不能做故障切换”，这是误解。真正阻碍切换的是 log_bin 未开启，而不是 log_slave_updates。
只要从库已启用 log_bin、有唯一 server_id 和 server_uuid，就能被提升为主库 —— log_slave_updates 只影响它能否继续向下复制，不影响自身升主能力。
- 若你不需要级联复制，就不要开
log_slave_updates；开了反而多一层 I/O、多一个维护点 - 若你确实需要级联（比如一主多从 + 从再挂从），那就必须接受它的开销，并配好
expire_logs_days和监控告警 - 最常被忽略的一点：开启后，
mysqlbinlog解析出来的事件顺序，和原始主库 binlog 并不完全一致（因 relay log 执行顺序受 SQL Thread 单线程限制），PITR 时需格外注意时间点校准
