必须关闭log_slave_updates的场景是纯读从库（不作为其他实例主库）；它唯一作用是让从库将relay log事件写入自身binlog，若无需级联复制、备份源或gtid切换，则该binlog冗余且浪费磁盘。
从库为什么会产生无用 binlog
从库默认不写 binlog，但一旦配置了 log-bin 却没配 log-slave-updates=1，就可能出现「写了 binlog 但内容不完整」的情况；反过来，如果开了 log-slave-updates=1 却没开 log-bin，MySQL 会直接报错启动失败。更常见的是：开了 log-bin 和 log-slave-updates=1，但没限制只记录必要库表，结果从库把所有同步来的事件（包括系统库、监控库、测试库）全记进自己的 binlog，既占磁盘又干扰后续级联复制判断。
必须关闭 log-slave-updates 的场景
绝大多数纯读从库（不作为其他实例的主库）应禁用该参数。它唯一作用是让从库把接收到的 relay log 事件再写一份到自己的 binlog 中——如果你不需要级联复制、不打算用这个从库做备份源、也不做 GTID 拓扑切换，那它产生的 binlog 就是冗余的。
-
log-slave-updates=0是默认值，但显式写出来更稳妥，避免被配置覆盖 - 若已开启且发现磁盘增长异常快，先确认
SHOW VARIABLES LIKE 'log_slave_updates';返回ON，再改配置并重启 - 云数据库（如阿里云 RDS）通常不开放该变量，无需操心；但自建环境务必检查
需要保留 log-slave-updates=1 的真实需求
只有当从库要承担「中间主库」角色时才必须打开，比如：主 → A（从库+主）→ B（A 的从库）。此时 A 必须把自己的 binlog 提供给 B 拉取，否则 B 无法构建完整复制链。
- 开启前提：A 已配置
log-bin，且server-id与主库、B 都不重复 - 若 A 还启用了复制过滤器（如
replicate-wild-do-table），它的 binlog 只包含被允许的事件——这是控制「有用 binlog」的关键出口 - 严禁在开启
log-slave-updates=1的同时使用binlog-do-db或binlog-ignore-db：这些是主库参数，从库上设了也无效，还容易误导排查
误开 log-bin 但不配 log-slave-updates 的后果
这种情况最隐蔽：从库启用了 log-bin，但 log-slave-updates 保持默认关闭。结果 MySQL 会生成空的 binlog 文件（如 mysql-bin.000001），文件头正常、大小为 154 字节，但里面没有实际事件。这类文件既不能被任何从库消费，又会被 PURGE BINARY LOGS 当作有效日志清理掉，导致 SHOW BINARY LOGS 列表混乱，甚至干扰监控脚本判断磁盘水位。
- 检查方式：
mysqlbinlog /var/lib/mysql/mysql-bin.000001 | head -20，若无SET @@session.或INSERT/UPDATE事件，基本可判定为空日志 - 根治方法：删掉当前空 binlog 文件，注释或删除从库配置中的
log-bin行，再重启 mysqld - 注意：不要用
RESET MASTER清空，它会重置所有 binlog 序列号，破坏已有复制状态
log-slave-updates，结果半年后发现从库磁盘被自己写的 binlog 塞爆——而这些日志从没被任何下游消费过。
